A member of my team had cloned our company’s repository with the wrong casing, e.g. if the repository is really
email@example.com:ACME/supersecret he cloned
firstname.lastname@example.org:acme/supersecret. Everything seemed to work but when sending out a diff using
arc, the push to staging step was a no-op, which was easy to miss and resulted in our remote build setup not getting triggered.
$ arc version arcanist db1959900a644d9b28064ec479af3296331d2a4f (4 Nov 2019) libphutil 1750586fdc50a6cd98adba4aa2f5a7649bd91dbe (30 Sep 2019)
- Take any existing GitHub repository already hooked up with Phabricator.
.git/configedit the origin
urland change the casing arbitrarily.
- Verify that
git fetchetc still works (GitHub is not sensitive to project name casing).
arc which, see that it fails to identify the repository.
- Make a commit and send it out for review with
arc diff. Because
arccan’t identify the repository, it doesn’t push the changes to our configured staging area. But the diff gets created successfully and associated with the correct repository in the Differential UI - I’m guessing this is done by parent commit hash because it works even if I make the URL in
(If needed I can write up full repro-from-zero steps but I expect the above is easier.)
a. Can the repository detection logic be made consistent between
arc and the serverside?
b. If not, can GitHub perhaps be special-cased so that project URIs are not case sensitive?
I did my testing on a Mac in case it matters, but I don’t think filesystem case sensitivity factors in here.