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.

I should read the blog first, next time...

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.

Happy enough for v1 for me.

Editing tasks via the editor now also subscribes me to them (eg https://secure.phabricator.com/T3277#148797); I don't think that's intended?

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 onscreen instructions for this adapter in the UI are also a bit out of date because the Google console has been updated since we wrote them. This is probably the next change to touch the provider, and should also look at modernizing the instructions.

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.

For completeness, T9953 / D14735 cleaned up an obscure rough edge on a narrow range of Git versions.

This is deployed and working properly.

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.

D14748 should fix the double feed stories.