lazygit Rebase/Fixup/Reword/Squash onto wrong commit (sibling branch) when git.log.showWholeGraph=true

[otakenz]

Describe the bug

When git.log.showWholeGraph is enabled or toggled using "Ctrl+L" in lazygit, rebasing or fixup/squashing/reword commits on a feature branch, a wrong rebase base is chosen that caused it to pulls in commits from sibling branches that share the same base (e.g., main or develop), even if those commits are unrelated to the current branch.

To Reproduce

Steps to reproduce the behavior:

1. Create two feature branches from main
2. Open lazygit with git.log.showWholeGraph : true (edit in config.yml or toggle using "Ctrl+L")
3. Checkout feature/B.
4. Perform a rebase or fixup on B1 (e.g., squash into previous or rebase onto main).
5. Observe: Commit A1 from feature/A now appears in the commit history/log of feature/B.

Expected behavior

1. Rebase/fixup on feature/B should only affect commits on feature/B.
2. Commits from feature/A should not be included ("pollution").
3. A rebase base should be chosen correctly.
4. This matches behavior when using git rebase directly in the CLI.

Screenshots

If applicable, add screenshots to help explain your problem.

1. Create two feature branches, here I call it "dev-a" and "dev-b", each has two commits branching off the main branch.

2. Now, I will checkout dev-b and perform "squash" by pressing "s". Observe that the "pollution" happened here, as the git graph now shows that commits in "dev-a" is being merged into the commit history of "dev-b"

3. Now I revert it, still checked out to "dev-b" branch and by using git CLI to perform squash the
   DESIRED OUTCOME is as shown.

git rebase -i HEAD~2

4. Another example, using lazygit rebase feature by pressing "i"

5. Same "pollution" happened here as well, this behavior has been replicable in fixup, reword as well, as long as the git log --all

Here onwards showcases some of my debugging efforts

1. Using lazygit --debug and lazygit --logs, when I perform rebase using lazygit by pressing "i".
   Here the base commit chosen is 333e0175a, this commit points to "dev-a" instead of "main" branch.

2. The function responsible for obtaining the base commits used in the interactive rebase, called by "quickStartInteractiveRebase"

Version info:

• Run lazygit --version and paste the result here
  commit=3de12b7fde56cec5d0fc27b1986180c27e50d971, build date=2025-09-17T18:42:05Z, build source=binaryRelease, version=0.55.1, os=linux, arch=amd64, git version=2.43.0

• Run git --version and paste the result here
  git version 2.43.0

Additional context

Add any other context about the problem here.

Note

Please try updating to the latest version or manually building the latest master to see if the issue still occurs.

[stefanhaller]

Thanks for the detailed reproduction recipes. This is a known problem, see #3608. It's also quite difficult to solve, because all of lazygit's code currently assumes that the model commits that we keep in memory correspond 1:1 to a --oneline log of the current branch. I don't have really great ideas what to do about that, but I feel it involves pretty heavy changes to how we represent commits in the model (as a tree rather than a slice). Until then, I feel the showWholeGraph feature should be avoided.

[otakenz]

Thanks for the detailed reproduction recipes. This is a known problem, see #3608. It's also quite difficult to solve, because all of lazygit's code currently assumes that the model commits that we keep in memory correspond 1:1 to a --oneline log of the current branch. I don't have really great ideas what to do about that, but I feel it involves pretty heavy changes to how we represent commits in the model (as a tree rather than a slice). Until then, I feel the showWholeGraph feature should be avoided.

Thanks for the reply. In the past two days I have been looking and getting my hands on this problem in my free time.
After getting my hands on, I have the same feeling as you that a clean and pretty fix would involves heavy changes.

However, #5008 is the simple approach I came up, it resolves most of the issue mentioned, except for interactive-rebase "i". Hoping to hear any feedbacks, thanks!

[balintbarna]

There is the same issue when using "Remove patch from original commit" as well.