turbolift icon indicating copy to clipboard operation
turbolift copied to clipboard

Conflicting forks aren't updated correctly from upstream

Open Dan7-7-7 opened this issue 4 months ago • 1 comments

We are pulling from upstream after cloning a fork to make sure we have the latest commits (see https://github.com/Skyscanner/turbolift/issues/80), but this doesn't work if there is a conflict, i.e. the default branch on the fork is both ahead and behind the upstream.

It also spoils the plan to clone with depth=1 (https://github.com/Skyscanner/turbolift/pull/123) because we're pulling down the entire commit history.

I've been thinking about some possible solutions to this. How about something like:

  1. fork & clone with depth 1
  2. get default branch name
  3. git fetch --depth=1 upstream [default branch]
  4. gh repo sync --force
  5. checkout branch

I think this would sync the (local) default branch with the upstream default while maintaining the shallow clone, and the --force flag would overwrite any commits on the fork that are ahead of upstream.

The only problem would be when the upstream default has changed from master to main since the fork, because as far as I can tell, gh repo sync relies on the branch names matching. In this scenario we could prompt the user to update their fork, unless we can successfully rename the branch in a way gh repo sync will understand.

(we could also do the pull from upstream/main in this situation, but it might get a bit complicated. There would then only be a problem if master/main had diverged AND there were conflicting changes.)

Dan7-7-7 avatar Mar 07 '24 14:03 Dan7-7-7