LazyGit: Sibling Commits Polluting Branch With Rebase/Fixup?

Oct 30, 2025 by SLV Team 61 views

Hey guys! Ever encountered a weird issue in LazyGit where your branch gets polluted with commits from sibling branches during a rebase, fixup, reword, or squash operation? This typically happens when the git.log.showWholeGraph setting is enabled. Let's dive into what causes this and how to work around it. If you're facing this problem, you're in the right place. This article will break down the bug, how to reproduce it, expected behavior, and provide some visual examples to make it crystal clear.

What's the Bug? The Pollution Problem

The core issue lies in how LazyGit handles rebasing or operations like fixup/squashing/rewording when the git.log.showWholeGraph setting is turned on. When this setting is active (either via your config.yml or toggled using Ctrl+L), these operations can inadvertently pull in commits from sibling branches that share a common base (like main or develop). This means commits unrelated to your current feature branch suddenly appear in its history, which is definitely not what you want!

In simpler terms, imagine you have two feature branches, feature/A and feature/B, both branching off main. When git.log.showWholeGraph is enabled, performing a rebase or squash on feature/B might mistakenly include commits from feature/A. This “pollution” can make your commit history messy and confusing, defeating the purpose of clean, isolated feature branches. This unexpected behavior can lead to significant confusion and a less maintainable commit history. When working in a collaborative environment, a clean and understandable commit history is essential. Polluted branches make it harder to track changes, revert problematic commits, and understand the evolution of the codebase. This is why understanding and resolving this issue is crucial for maintaining a healthy development workflow.

To emphasize, the key problem occurs because LazyGit, with git.log.showWholeGraph enabled, incorrectly merges the commit history from sibling branches during rebase or similar operations. This deviates from the expected behavior where only commits within the current branch should be affected. Understanding this distinction is crucial for troubleshooting and preventing such issues in the future. Moreover, polluted histories can complicate code reviews. Reviewers might mistakenly believe that certain changes belong to a feature when they actually originated from a different branch. This can lead to incorrect feedback and potentially introduce bugs into the codebase. Therefore, it's important to ensure that LazyGit and other Git tools behave predictably and isolate changes to their respective branches.

How to Reproduce the Bug: A Step-by-Step Guide

To really understand this bug, let's walk through the steps to reproduce it. Trust me, seeing it in action makes the issue much clearer. Follow these steps, and you'll see exactly what we're talking about:

Create Two Feature Branches: Start by creating two feature branches from your main (or develop) branch. For example, let's call them feature/A and feature/B. These branches will serve as our test subjects. You can use these commands:
```
git checkout main
git checkout -b feature/A
# Make some commits on feature/A
git checkout main
git checkout -b feature/B
# Make some commits on feature/B
```
Open LazyGit with git.log.showWholeGraph Enabled: Now, open LazyGit. Make sure git.log.showWholeGraph is enabled. You can either set this in your config.yml file or toggle it within LazyGit using Ctrl+L. This setting is the trigger for the bug.
Checkout feature/B: Switch to the feature/B branch in LazyGit. This is the branch we'll be performing our rebase/fixup operation on.
Perform a Rebase or Fixup: On feature/B, perform a rebase or fixup operation. For instance, you might squash a commit into the previous one by pressing s on a commit. Alternatively, you can try rebasing onto main.
Observe the Pollution: This is the critical step. Look at your commit history in LazyGit. You'll notice that commits from feature/A are now appearing in the commit history of feature/B. This is the “pollution” we're talking about – commits from one branch bleeding into another.

By following these steps, you can consistently reproduce the bug and see firsthand how git.log.showWholeGraph can cause issues during rebasing or similar operations. This hands-on experience is invaluable for understanding the problem and seeking effective solutions. Remember, the key here is the presence of sibling branches sharing a common base and the activation of git.log.showWholeGraph. These conditions create the perfect storm for the bug to manifest itself. Therefore, when troubleshooting, always check these factors first.

Expected Behavior: What Should Happen?

Okay, so we've seen the bug in action. But what's the expected behavior? What should happen when we rebase or fixup commits? Let's clarify the desired outcome to better understand the issue.

Rebase/Fixup Should Affect Only the Current Branch: When you perform a rebase or fixup on feature/B, the operation should only modify commits within feature/B. This is the fundamental principle of branch isolation in Git.
Commits from Other Branches Should Stay Out: Commits from feature/A (or any other branch) should not be included or affected during operations on feature/B. Each branch's history should remain independent and clean.
CLI Git Behaves Correctly: The behavior in LazyGit should match what you'd expect from using Git directly in the command-line interface (CLI). When you run git rebase in the CLI, it correctly operates within the current branch without pulling in unrelated commits. This consistency between LazyGit and the Git CLI is crucial for a predictable and reliable workflow. Deviations can lead to confusion and errors.

In essence, the expected behavior is that rebase and fixup operations should be localized to the branch you're working on. This ensures that your commit history remains clean, manageable, and accurately reflects the changes within that specific feature or task. When LazyGit deviates from this expectation, it can create significant headaches and undermine the benefits of using feature branches in the first place. Maintaining a clear understanding of these expectations helps in quickly identifying and addressing any deviations caused by bugs or misconfigurations. By comparing the actual behavior with the expected behavior, developers can effectively diagnose issues and implement the necessary corrective measures. This clarity also helps in communicating the problem to other team members and contributors, facilitating collaborative troubleshooting and resolution.

Visual Examples: Screenshots Speak Louder Than Words

To really drive the point home, let's look at some screenshots that illustrate the bug. These visuals will make it super clear what's happening under the hood. These screenshots will walk you through the pollution problem step by step.

Initial State: Two Feature Branches: Here, we have two feature branches, dev-a and dev-b, each with two commits branching off the main branch. This is our starting point.
The Pollution: Squash Operation: Now, we checkout dev-b and perform a squash operation by pressing s. Observe the pollution! The Git graph now incorrectly shows commits from dev-a being merged into dev-b's commit history.
Desired Outcome: Git CLI to the Rescue: Reverting the changes and using Git CLI to perform the squash operation gives us the desired outcome. The commit history of dev-b remains clean, without any contamination from dev-a.
```
git rebase -i HEAD~2
```
Rebase Example: More Pollution: Another example, this time using LazyGit's rebase feature by pressing i.
Same Pollution, Different Operation: The same pollution issue occurs here. This behavior is replicable in fixup and reword operations as well, as long as git log --all is enabled. This was tested on multiple LazyGit versions (0.55.1, 0.46.0, 0.33).

These screenshots clearly show the issue of sibling commits polluting the branch history when git.log.showWholeGraph is enabled. By visually comparing the polluted history with the desired outcome, the problem becomes much more apparent. This visual confirmation is crucial for developers to understand the scope and impact of the bug. It also aids in communicating the issue to other team members or when reporting bugs to the LazyGit maintainers. The ability to visually demonstrate the problem can significantly speed up the debugging and resolution process.

Version Info: Tracking Down the Culprit

To help diagnose the issue, it's essential to know the versions of LazyGit and Git you're using. This information can help determine if the bug is specific to a particular version or a more general problem. Here’s how to find this info:

LazyGit Version: Run lazygit --version in your terminal. This will give you the commit hash, build date, version number, OS, architecture, and Git version used by LazyGit. For example:
```
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
```
Git Version: Run git --version in your terminal. This will show you the version of Git installed on your system. For example:
```
git version 2.43.0
```

Knowing these versions is crucial because bugs can be version-specific. If a bug is reported in a particular version of LazyGit, it's helpful to know if it has been fixed in a later version. Similarly, certain Git versions might interact differently with LazyGit, potentially triggering or resolving issues. This information is invaluable when reporting bugs or seeking help from the community. Including version details in bug reports helps developers reproduce the issue and identify the root cause more efficiently. Moreover, tracking version information over time can help identify regression issues, where a previously fixed bug reappears in a later version. This is particularly important in software development where frequent updates and changes are common.

Additional Context and Potential Solutions

So, what else should you know about this issue? And more importantly, how can you work around it? Let's dive into some additional context and potential solutions. Firstly, if you encounter this bug, try updating to the latest version of LazyGit or manually building the latest master branch from GitHub. Sometimes, the issue might have already been addressed in a newer release. Staying up-to-date with the latest version is generally a good practice for any software, as it often includes bug fixes, performance improvements, and new features.

However, if updating doesn't resolve the problem, you might need to adjust your workflow temporarily. One workaround is to disable git.log.showWholeGraph when performing rebasing or similar operations. You can toggle it off using Ctrl+L before running the operation and then re-enable it afterward. While this adds an extra step, it prevents the pollution issue. Alternatively, you can perform these operations using Git CLI, which, as we've seen, doesn't exhibit this behavior. This can be a reliable way to ensure that your commit history remains clean and isolated. Another important aspect to consider is the complexity of your Git workflow. If you have a large number of branches and frequent rebasing operations, this bug can become particularly disruptive. In such cases, it might be beneficial to review your branching strategy and consider alternative approaches that minimize the need for rebasing while git.log.showWholeGraph is enabled.

Conclusion: Staying Vigilant and Keeping Your History Clean

In conclusion, the bug where LazyGit pollutes branches with sibling commits during rebase/fixup operations (when git.log.showWholeGraph is enabled) can be a real headache. But by understanding the cause, knowing how to reproduce it, and being aware of potential workarounds, you can navigate this issue effectively. Remember, a clean commit history is essential for collaboration and maintainability. Stay vigilant, and keep your history clean!

By understanding the bug, how to reproduce it, and potential workarounds, you're well-equipped to handle this issue in LazyGit. A clean and accurate commit history is crucial for effective collaboration and maintainability, so taking the time to address this problem is well worth the effort. Keep your eyes peeled for updates and fixes, and until then, happy coding! If you guys encounter any similar issues, be sure to check the LazyGit GitHub repository for updates and discussions. Reporting your experiences can also help the community and maintainers in identifying and resolving such bugs more efficiently. Remember, open-source projects thrive on community contributions, so your feedback is valuable! Finally, always back up your work and proceed with caution when performing Git operations, especially when dealing with complex scenarios or potential bugs. This can save you from unexpected data loss or irreversible changes. Git is a powerful tool, but it's essential to use it wisely and with a good understanding of its capabilities and limitations.