I am in the same boat as @hach-que right now. By destroying the original behavior, it really doesn't leave me any choices but to orphan everyone that I have trained to use arcanist on a very old version of the tool. I am 100% trusting of arcanist and its operations, but many people are afraid of tools like this. So they like options like --hold that allow them to inspect everything before they push it away. But now they would be instructed by the tool to run some funny command whose syntax they don't understand, and then also have to run

• git checkout master
• git pull

to get to where they wanted to be.

Actually it looks like msysgit finally released Git 2.x for Windows, which is supposed to have fixed the race condition that was present on Windows in Git (that was supposedly the cause of the issue). When I return I'll get everyone to update in the hope that fixes the issue.

I believe this change will negatively affect the workflows we have at our workplace (when I return there I'll know for sure). Basically, we advise everyone to land with arc land --hold due to issues where interactions with msysGit and arc will cause commits to revert part of the branch (I can't find the task, it was filed ages and ages ago). So not being able to just check the landed commit to make sure it's okay and then hitting push will be a regression in the workflow that people are currently using...

Thanks for digging into this! That explanation makes SVN's behavior a lot more reasonable.

Sure. The best "Next Step" is to just run arc land <branch> again without --hold, although we can be explicit about that and fill in branch in case it was run as plain arc land originally.

I've often told people that they can use arc land --hold to inspect the changes before they are pushed (mostly for people who were not completely trusting of arc land. Whilst this is still technically true, I suspect that many people would not know what git push origin HEAD:master does (I personally had never seen this command before this task). It might be useful to output some sort of "Next Step" text when using arc land --hold.

I also tested on latest arc version no change:
/data/arc/arcanist/bin/arc version
arcanist dae2f0073f019221839924b4b1431c6cba5dcdda (10 Dec 2015)
libphutil 230c3e161c9ad7ee920d003b53e7c4a473a46207 (7 Dec 2015)

Right, I think I have found the cause. The binary_safe_diff.sh does not preserve the exit code of diff, and it returns 0 even if diff returned 1. Apparently returning 0 causes Subversion 1.9 to emit the file headers again.

The @local part is because I have cluster.instance configured locally, it's normal for it to not be present on regular installs.

I haven't been able to trace the cause of the issue, but I do have something to add:

There shouldn't be any caches.

• We can't give arc land the old behavior without breaking other (more common) use cases.
• You can push directly from the detached head, per above.
• arc help land is now more clear that merging takes place in a detached state and local branch references are not updated.
• arc cleanup (T3277) may eventually make it easier to clean up these branches.
• It sounds like the old workflow was still fairly labor intensive. Writing a script to help you manage submodules might simplify your workflow overall, as a possible workaround. This script could use slightly lower-level operations than arc land (like git operations and arc amend) to give you more control. arc land does not do anything magical, and is just intended as a convenience wrapper around merging in the most common cases.

Yes, 6 months is a huge amount of time in the scale of arc, although that version is probably new enough to have D9921 (although I don't know if July 26 is the changes it actually includes, or just the date someone might have published some earlier version, and have no idea what _2 means).

The change is merged into the destination branch, but the branch reference is not updated to point to it. The detached HEAD you end up with is the correct state of a merge between the origin branch and the changes you are landing. The documentation could perhaps be more explicit about this.

I don't see any way in the code that it can possibly render src="PHID-FILE-...", am I misunderstanding?

Ah, please ignore my comment about the src, it was misinformed.

Since the change is not merge onto to the destination branch

Also, I noticed that the documentation for --hold is also out of date, in accordance with this bug report.

The change is merged into the target branch, following these rules:

For me this gives:

T5555 and D9921 are earlier similar interactions, where file content could be doubled with newly added directories.

Well realistically, there more steps between the arc land --hold and git push

Can you show me the output of arc version?

I can't reproduce that. Here's what I did:

Hmm, this seems to be caused by Subversion 1.9 (which is the default in the FreeBSD ports collection). If I use Subversion 1.8 to run the svn diff --depth empty --diff-cmd '/usr/local/lib/php/arcanist/scripts/repository/binary_safe_diff.sh' -x -U32767 foo.txt command, the output is:

Minor issue still present. On the "confirm registration" page, the image shown is still a blank one. (Inspecting the element in browser shows its src = PHID-FILE...)

Why are you using --hold if your next steps are the steps that arc land would take anyway?

Additionally, the hold now does not cleanup the feature branch either

I expect it to do what it used to do previously, which would be finish with a merge onto the desired landing branch. Rather now, if I use this, I have to do an additional

• git checkout master (remembering the commit I am leaving behind)
• git merge eb35b52

Then end with
git push

What do you expect it to do?

Thanks for the exceptionally clear report

☺

This should be fixed in HEAD. Thanks for the exceptionally clear report, and let us know if you run into anything else.

The UI instructions about navigating the dashboard are also a little out of date since that UI has changed, although I was still mostly able to figure out what they meant. I'll leave a note on T5591 to update them when that gets fixed.

The Google+ API for a person, available for reference at https://developers.google.com/+/web/api/rest/latest/people#resource, does not agree with what libphutil's PhutilGoogleAuthAdapter.php does currently to extract a profile pic.

I added some properties:

Adding Eitan, since he's our Phabricator wrangler.

I think the problem is because of Subversion automatic properties. For the FreeBSD Subversion repository, automatic properties get added, like this:

Also, arc sometimes has issues with non-English locals - see T5554.

phutil_is_windows()

Yes, we can't help with this without better reproduction steps. In particular, I can't reproduce this. Here's what I did:

Please see Contributing Bug Reports. Specifically, concise steps to reproduce and version of Phabricator are needed.

An example if this bug can be seen here: https://reviews.freebsd.org/differential/diff/11161/
The three added files should have contents.

Ah that makes sense, when I load a page on my iPhone (iOS 9.1) it shows desktop site and flashes down to mobile. I guess the server thinks I'm a desktop. Note this happens even on an iPhone 4s simulator (the oldest version I can run).

The 1-up renderer is server-side, it's not responsive CSS. Reload the page after you shrink.

I was able to repro on Mac OS X with a recent version of chrome.

I'm on iOS 9.2

In Safari/iOS I intermittently get the desktop site. No issues in Chrome.

That screenshot was taken as a 'logged out' user. There were two columns (so not unified diffs?)

iPhone 5s simulator

Oh, there are only two options and neither would break this.

Is Settings → Diff Preferences → Show Unified Diffs set to "On Small Screens" (the default) for you?

D14747 should fix this. I haven't pushed that yet, but I updated all the changelogs.

The URI scheme changed but this shouldn't fatal. I'll fix the fatal and then go fix the links in the changelogs, there are only like 6 of them or something.

Looks like the URL scheme migh thave just changed? I was able to get to the post by navigating to phame home: https://secure.phabricator.com/w/changelog/2015.49/

I think this should now be fixed in HEAD. Let us know if we missed anything, and thanks for the report.

Without steps to reproduce the issue, what specifically do you suggest we do with this ticket?

In T9966#148595, @epriestley wrote:

So you haven't actually reproduced this yourself? Is it possible that the user mistook xxxxx as uncensored credentials? Can you try reproducing it directly?

I can't reproduce this locally even with a username email.

That prioritization makes sense to me. It doesn't seem worth putting a lot of effort into optimizing the workflow for a bad configuration.

So you haven't actually reproduced this yourself? Is it possible that the user mistook xxxxx as uncensored credentials? Can you try reproducing it directly?

I should note that we're running the latest version of Git (2.6.3) which could be the culprit. From my superficial inspection of the code, it appears that the output of git fetch is simply reflected.

In T9966#148590, @epriestley wrote:

In your report, you say <user email address> -- is the login username for this user a string including "@"? Does the UI print out a message like this?

https://xxxxx@domain.com:password@remote.example.com/...

..that is, the beginning of the email address is censored, but the rest of it is not and the password and domain are not? Or is the HTTP username not really an email address?

I should note that we're running the latest version of Git (2.6.3) which could be the culprit. From my superficial inspection of the code, it appears that the output of git fetch is simply reflected.

In your report, you say <user email address> -- is the login username for this user a string including "@"? Does the UI print out a message like this?

I think this is worth improving. However, I think it is not a very important feature in situations where things are set up reasonably well (not too many lint false positives, fairly fast tests or server-side CI), and that fixing these problems will have a lot of other benefits in cases where they aren't working well. That is, this should be more like a "nice-to-have" that saves you a few seconds once a week, not something you're hitting on >50% of revisions.

I was able to get some metrics for how many revisions have lint errors in this particular project (repo callsign 'C') with this query:

What version of Phabricator are you running? (You can find this in Config → Versions for recent versions.)

Awesome, good to hear.

Yep, that did the trick for me. Sometimes your are just to blind to see. Thank you guys for your help. Phabricator works now perfectly.

I'd focus on getting the user access to create databases, you'll want it in the future as well to streamline updates.