Conflicting forks aren't updated correctly from upstream

[Dan7-7-7]

We are pulling from upstream after cloning a fork to make sure we have the latest commits (see #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 (#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]

another option could be to checkout first, then reset using the upstream default branch as the argument

[rnorth]

We think this is still a problem, but not one where solving it outweighs the complexity that we'd be adding. For now we're inclined to park.

[Dan7-7-7]

a better solution might be to error more helpfully when the pull from upstream fails due to conflict