Page MenuHomePhabricator

Simplify "git fetch" behavior in the Pull daemon
ClosedPublic

Authored by epriestley on Mar 14 2017, 10:37 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 17, 11:38 PM
Unknown Object (File)
Thu, Nov 14, 12:45 AM
Unknown Object (File)
Sat, Nov 9, 4:05 PM
Unknown Object (File)
Sat, Nov 9, 1:07 PM
Unknown Object (File)
Wed, Nov 6, 8:09 AM
Unknown Object (File)
Oct 22 2024, 11:30 PM
Unknown Object (File)
Oct 22 2024, 8:26 PM
Unknown Object (File)
Sep 21 2024, 7:13 PM
Subscribers
None

Details

Summary

Ref T12392. The logic currently goes like this:

  • Try a fetch.
  • If that fails, try repairing the origin URI.
  • Then try again.

This is pretty complicated, and we can use this simpler logic instead:

  • Set the origin URI to the right value.
  • Try a fetch.

Setting the origin URI is very fast. This can normally only get us in any trouble in very obscure situations which haven't occurred for many years:

  • Pretty much all of this is already covered by verifyGitOrigin(), which we run earlier.
  • Origins could be configured to have multiple URIs for some reason, but shouldn't be.
  • Years ago, you could configure Phabricator to point at a local repository it didn't own and that could conceivably have a different "origin" that you might not want us to delete. If you did this, the daemons have been spewing errors for 3-4 years without you fixing it. The cost of fixing the remote URI is very small even if anyone is affected by this (just set it back to the old value) and there's zero reason to do this and the scenario is ridiculous.
Test Plan

Ran bin/repository update PHABX --trace --verbose, saw fetches go through cleanly after URI adjustment.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable