Page MenuHomePhabricator

Simplify non-bare working copy rules for the new "git fetch" strategy
ClosedPublic

Authored by epriestley on Apr 18 2019, 1:58 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Jan 21, 4:03 PM
Unknown Object (File)
Wed, Jan 8, 5:56 AM
Unknown Object (File)
Mon, Jan 6, 7:59 AM
Unknown Object (File)
Dec 19 2024, 1:02 AM
Unknown Object (File)
Dec 17 2024, 5:16 AM
Unknown Object (File)
Dec 6 2024, 7:19 PM
Unknown Object (File)
Nov 26 2024, 8:10 PM
Unknown Object (File)
Nov 26 2024, 6:31 AM
Subscribers
None

Details

Summary

Ref T13280. In D20421, I changed our observe strategy to git fetch <uri> in all cases.

This doesn't work in an ancient, non-bare repository if master is checked out and master is also fetch: git refuses to overwrite the local ref unless we pass --update-head-ok. Pass this flag.

Also, remove some code which examines branches and tags in a special way for non-bare working copies. The old git fetch <origin> code without explicit revsets meant that refs/remotes/orgin/heads/xyz got updated instead of refs/heads/xyz. We now update our local refs in all cases (bare and non-bare) so we can throw away this special casing.

Test Plan
  • Replaced a modern bare working copy with a non-bare working copy by explicitly using git clone without --bare.
  • Ran bin/repository update, hit the --update-head-ok error. Applied the patch, got a clean update.
  • Used the "repository.branchquery" API method...
    • ...with "contains" to trigger the "git branch" case. Got identical results after removing the special casing.
    • ...without "contains" to trigger the "low level ref" case. Got identical results after removing the special casing.
  • Grepped for isWorkingCopyBare(). The only remaining callsites deal with hook paths, and genuinely need to be specialized.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable