Stacking should handle rebases performed outside of gh stack

[flakey-bit]

Let's say I have

trunk: AA1
    branch1: BB1
        branch2: CC1

The stack JSON will look something like this

{
  "schemaVersion": 1,
  "stacks": [{
      "trunk": {
        "branch": "master",
        "head": "AA1"
      },
      "branches": [{
          "branch": "branch1",
          "head": "BB1",
          "base": "AA1",
          "pullRequest": {
             // ...
          }
        }, {
          "branch": "branch2",
          "head": "CC1",
          "base": "BB1",
          "pullRequest": {
            // ..
          }
        }
      ]
    }
  ]
}

If I now perform an interactive rebase (outside of gh stack) - e.g. to remove the head commit from branch1, or if I do something like git reset HEAD^1 --hard from a branch1 checkout, the stack has no knowledge of what has happened.

If I view the stack, there's now one fewer commit on branch1 (as expected) but one extra commit on branch2. I'd like / expect that commit to have been removed entirely from the stack.

[mattnotmitt]

This also happens if one runs a git commit --amend on branch1. After the rebase for branch2, a commit reverting those changes (with the same message as the amended one) shows up on branch2.

[patroza]

yes, this is a major missing flaw, especially when remote agents work on the stack.

[PolyFlyx-EFerry]

This also happens if one runs a git commit --amend on branch1. After the rebase for branch2, a commit reverting those changes (with the same message as the amended one) shows up on branch2.

What's even worse, is that if you do gh stack rebase --no-trunk --upward, this duplicated commit is prone to conflict, thus making the whole rebase a conflict.

It would be lovely to have a way to be able to re-write history, and that it could be reflected on the stack. It's even more annoying when working with "deep" stacks. It's either you handle conflict with gh stack rebase, or you remove the commit with git rebase --onto branch-with-dup-commit dup-commit-hash. Doing the later will spread the commit to the next level, and you have to repeat the process until you reach the top