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)
Fri, Apr 5, 7:10 PM
Unknown Object (File)
Fri, Apr 5, 11:55 AM
Unknown Object (File)
Sat, Mar 30, 4:18 AM
Unknown Object (File)
Mar 10 2024, 4:36 AM
Unknown Object (File)
Feb 25 2024, 7:32 PM
Unknown Object (File)
Feb 3 2024, 3:07 PM
Unknown Object (File)
Jan 22 2024, 10:12 PM
Unknown Object (File)
Dec 24 2023, 9:56 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
Branch
ref2
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 15985
Build 21184: Run Core Tests
Build 21183: arc lint + arc unit