Wrong commit is focused after moving a commit past a branch boundary

[slieschke]

Describe the bug
Using rebase.updateRefs set to true in Git config, when moving a commit past a branch boundary the focused commit changes.

To Reproduce
Steps to reproduce the behavior:

1. Starting from the Git state in the screenshot below, add a new commit with summary Part 1, Commit 3
2. Focus the commit in the Commits panel and use to move the commit down twice. The commit is now located between Part 2, Commit 1 and Part 1, Commit 2 at the HEAD of the feature/part-1 branch.

Expected behavior
The Part 1, Commit 3 commit remains focused in the Commits panel.

Actual behavior
The Part 1, Commit 2 commit is now focused in the Commits panel.

Moving a commit up past a branch boundary with also results in the focused commit unexpectedly changing.

Screenshots

Version info:
commit=, build date=, build source=homebrew, version=0.44.1, os=darwin, arch=arm64, git version=2.47.0
git version 2.47.0

[stefanhaller]

That's true, I have run into this too. To work around it, I have gotten used to typing i to enter an interactive rebase for the whole stack, and then move the commits. This gives you full control over whether your moved commit(s) go before or after an update-ref todo, it doesn't have the selection issue, and it's also faster anyway (in a larger code base, at least).

Still, it would be nice to fix this, but I'm actually not sure if the selection behavior should be fixed or the moving behavior. The issue exists because moving the commit down only moves it past the update-ref todo (which is not an entry in the commits list); we could fix the problem also by moving it past the next real commit, in which case the selection would be correct again. If we keep the behavior the way it is (and only fix the selection), the only thing that would happen is that you see the branch head icon move up by one, which could be rather confusing. On the other hand, it does give you more control over where exactly your commits go, once you understand what happens.

Any opinions?

[slieschke]

To work around it, I have gotten used to typing i to enter an interactive rebase for the whole stack, and then move the commits.

Aha, yes; I'd figured the same thing after raising this issue.

Any opinions?

I'd lean towards fixing the selection behaviour. While potentially confusing it conceptually aligns with what happens when moving a commit past an update-ref todo when interactively rebasing. If the commit panel was expanded with + the change would be more obvious as you'd see the entire branch name move up by one.

[stefanhaller]

I'd lean towards fixing the selection behaviour.

I tried implementing that, but it's surprisingly hard. The other option was much easier to implement, so I went with that for now (and I think it doesn't matter too much which approach we take, as long as it isn't broken). Here's a PR: #4096.