Just for visibility, this is I believe the change that broke Diffusion (which was fixed in rP52df4ff515b7), where the error message is something like

I believe these were all hunted down.

I deployed this everywhere in the Phacility cluster yesterday and things have been quiet, so I'm assuming it worked until evidence arises to the contrary.

D21756 effectively makes all Git pathways call setSudoAsDaemon(true).

Just for visibility, the error messages you'll see if you're affected by this issue look something like this:

...maybe this is an actual bug in Phabricator where some pathways are just missing the "sudo" wrapper?

Yes. I closed down registration on this install (secure.phabricator.com) several years ago because the overwhelming majority of users who registered accounts here didn't read or follow the rules. Access to secure.phabricator.com is now invite-only.

In T13589#254320, @epriestley wrote:

Please use Discourse to report bugs.

Please use Discourse to report bugs. See https://discourse.phabricator-community.org/t/repository-view-git-command-failed-error/4510/.

It works with Git 2.1.4 (shipped with Debian Wheezy), but not with Git 2.20.1 (shipped with Debian Buster), or Git 2.30.0 (latest version).

My apologies if this is not the right place to post about this, but seems like due to ea9cb0b625fb6922c45aecbfdebacc60788ed92d we now get following error message when visiting diffusion repository page, i.e. URL /diffusion/$REPOID/:

This is a duplicate of T8936 and resolved by D20420.

D20420 accepts these refs. We don't show notes in the UI, but we have no outstanding customer requests for this.

T1022 is possibly somewhat-vaguely-adjacent on symlink stuff.

@jcox do you know how to reproduce arc diff dying when you try to create certain types of diffs that move or remove symlinks? I think that's adjacent, if not identical to what's being talked about here.

As a special case of this, if you commit an empty a.py file, then add content to it and also add a new empty b.py file in a commit on top of it, the new empty b.py will be detected as a copy of a.py based on the previous (empty) content of the file. I think Git is being pretty reasonable/consistent here, but this is potentially also expectation-defying:

Duplicate of T8936?

I'm not totally sure all variants of this are fixed, but I don't know how to reproduce any remaining issues.

I filed a summary of this in the Mercurial upstream to waste someone else's time so I feel better:

This is an explicit behavior in Mercurial and dates from 2007: