gs repo sync initiated restack sometimes results in merge conflicts for unrelated files

[amay]

I've been running into a persistent issue when stacking branches where when I merge a base branch and then do a gs repo sync call, gs detect sthat the base branch was merged and then while attempting to restack (rebase) the stacked branch I get merge conflicts for files that have nothing to do with my branches.

Here is an example:

❯ gs repo sync --verbose
DBG trunk is at or behind remote: fetching changes
DBG Fetching from remote  name=origin
DBG git fetch: warning: fetch normally indicates which branches had a forced update,
DBG git fetch: but that check has been disabled; to re-enable, use '--show-forced-updates'
DBG git fetch: flag or run 'git config fetch.showForcedUpdates true'
INF master: already up-to-date
INF BASE_BRANCH: #397958 was merged
DBG Changing upstack branch to a new base  branch=STACKED_BRANCH base=master
DBG Moving commits onto new base  branch=STACKED_BRANCH oldBase=BASE_BRANCH newBase=master commits=faec14c..e6a0434
DBG Rebasing branch  name=STACKED_BRANCH onto=ec6ecb577a12ad1b5d959ecc64625f8113340fdb upstream=faec14c2a8ae1eb63ef924a7981d3035edd3ee78
DBG git rebase: dropping 3fe71ea2e17630928bba64ebb7bda2beff77de1f <SOME UNRELATED COMMIT MESSAGE> -- patch contents already upstream
DBG git rebase: error: could not apply 14cbc1da8ddb... <UNRELATED COMMIT MESSAGE> (#396984)
DBG git rebase: Recorded preimage for '<some_file>'
DBG git rebase: Could not apply 14cbc1da8ddb... <UNRELATED COMMIT MESSAGE> (#396984)
ERR There was a conflict while rebasing.
ERR Resolve the conflict and run:
ERR   gs rebase continue
ERR Or abort the operation with:
ERR   gs rebase abort
DBG Pushed rebase continuation  command=branch delete --force BASE_BRANCH branch=STACKED_BRANCH
FTL gs: delete merged branches: rebase of STACKED_BRANCH interrupted by a conflict: exit status 1

If I abort that rebase attempt and instead run git rebase origin/master the rebase works fine so I'm unclear what gs is doing differently. The commit it is having issues with (14cbc1da8ddb) is not related to my changes.

I ensured master was synced with origin/master in this example & the onto SHA (ec6ecb577a12) is what both master and origin/master are pointing to.

I work around it right now by rebasing manually, untracking the base branch and deleting. This definitely hasn't always been an issue and it doesn't always happen (e.g. I'm working on merging a pretty deep stack right now and it has been working fine).

[abhinav]

Couple questions:

• Confirming: from the debug logs, commit faec14c is unrelated? (It should be the old/local base branch head being deleted.)

• Are you using multiple Git worktrees?

• Are you doing squash-merge or merge commit?

• Next time you encounter this, would you mind sharing the output of the following commands:

  git cat-file -p refs/spice/data:branches/$BASE_BRANCH
  git cat-file -p refs/spice/data:branches/$STACKED_BRANCH
  

  (Feel free to obfuscate the branch names, gqlIDs, and comment URLs as you see fit.)

  It would be useful to see these values at the time of conflict (in the rebase conflict error), and when you abort the rebase (equivalent to the "before" state).