Accepting a messy git history

# Accepting a messy git history Source: [https://beza1e1.tuxen.de/git_two_users.html](https://beza1e1.tuxen.de/git_two_users.html) As GitHub just released[stacked pull requests](https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/), the discussion around it reveals two kinds of git users: 1. Those who**commit often**and without much thought\. 2. Those who**rebase carefully**to craft a clean history\. The commit\-often people consider the rebase people as wasting time with pointless activities\. A fine\-grained history reflects how development actually happened\. The rebase people consider the commit\-often people as lazy and careless\. Only with a clean history will it be possible to understand the intentions behind changes\. ## When stacking pull requests Looking at[the HN discussion](https://news.ycombinator.com/item?id=49112232), you can see the commit\-often people celebrating\.[Steve Klabnik](https://news.ycombinator.com/item?id=49114492): > This is one of the biggest changes to hit GitHub in many years\. I'm really glad to see something like this deployed to one of the largest forges in the world, hopefully it will expose a lot of developers to workflows that they didn't even know about before\. Meanwhile, the rebase people are puzzled, why anybody would want this\.[Insimwytim](https://news.ycombinator.com/item?id=49113869): > I feel like many people \(and industry in general\) complicate things unnecessary\. ## When merging pull requests At work, we have a similar discussion about merging pull requests to main and if squashing is a good idea or not\. The rebase people are angry if their carefully crafted history is destroyed by a squash merge\. They prefer merge commits, such that every commit is preserved\. The commit\-often people love squash merges because it makes the history cleaner and easier to read\. While it might be useful to have every step on a branch preserved as a separate commit, this messy history is not needed on the main branch\. ## Who is right? Personally, I'm more of a rebase person\. However, it requires discipline which is hard to maintain in larger organizations\. If a clean history is not enforced very strictly, then the git history will become a mess\. According to the[broken window theory](https://en.wikipedia.org/wiki/Broken_windows_theory)it tends to become worse and team rebase will eventually give up\. Thus commit\-often seems to be the more resilient approach and resistance is rather futile\. So unless I have the authority over a git repository, I shall make peace with a messy history\. There are two kinds of git users: those who commit often and those who rebase carefully\.