--- title: Accepting a messy git history | daily.dev description: GitHub's stacked pull requests launch has reignited a long-standing debate between two camps of git users: those who commit often and embrace messy histories,... canonical: https://daily.dev/posts/accepting-a-messy-git-history-96mlbskre twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Accepting a messy git history | daily.dev og:description: GitHub's stacked pull requests launch has reignited a long-standing debate between two camps of git users: those who commit often and embrace messy histories,... og:url: https://daily.dev/posts/accepting-a-messy-git-history-96mlbskre og:image: https://api.daily.dev/og/posts/96MLbSkrE.png og:image:alt: Accepting a messy git history og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Accepting a messy git history **[Lobsters](https://daily.dev/sources/lobsters)** · 2 min read · 1 upvotes · 0 comments ## Summary GitHub's stacked pull requests launch has reignited a long-standing debate between two camps of git users: those who commit often and embrace messy histories, and those who rebase carefully to craft clean, intentional histories. The same tension plays out in squash-vs-merge debates when closing pull requests. The author, personally a rebase advocate, concludes that the commit-often approach is more resilient in larger teams because maintaining a clean history requires strict discipline that tends to erode over time — making acceptance of messiness the pragmatic choice. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 1 discussion and 21 comments across lobsters (as of 2026-08-03). **TL;DR:** The Lobsters community largely agrees that messy histories are pragmatic but debates the value of git history at all — with some heavy users of git blame and log pushing back, and stacked PRs emerging as a popular middle-ground solution. **Sentiment:** 25% positive · 55% mixed · 20% skeptical **The case for** - Stacked PRs offer a practical middle ground that satisfies both commit-often and rebase camps while improving code review ergonomics. - Squash-merge at the repo level provides a reasonable minimum floor of cleanliness without requiring strict discipline from contributors. - Smaller, focused PRs are much easier and faster to get reviewed and approved than large monolithic ones. **The pushback** - Force-squashing destroys granular history that can be critical for reverting specific changes, as illustrated by a real-world example where cherry-picking from the original branch was the only rescue. - Git history is genuinely valuable for understanding intent behind code — some developers consult git blame weekly and cite 30-year-old histories as useful. - The article conflates two distinct uses of rebase (interactive history curation vs. pull-rebase for linear history), muddying the debate. **By community** - lobsters (mixed): Commenters are split between those who rarely consult git history and find messiness acceptable, and those who rely on git blame regularly and advocate for stacked PRs or squash-merge as pragmatic compromises. **Hottest debate:** Whether git history is actually useful enough in practice to justify the discipline required to keep it clean, with some developers checking it weekly and others almost never. **Open questions** - Does the complexity of a codebase in a developer's early career shape their preference for clean vs. messy history? - How well do stacked PRs scale for parallel feature development compared to a DAG-based workflow (e.g., jj)? - Should commit history hygiene be enforced via tooling (branch protection, conventional commits) rather than team discipline? **Highlights** > I really like stacked PRs, but not for any reason mentioned in the blog post. Personally, I think stacked PRs are significantly easier to get reviews and approvals for, and to get merged. A single PR with multiple commits is hard to review because the tooling sucks. GitHub is really awful at separating this, and it's not immediately obvious a PR should be reviewed commit-by-commit, or if the commits are all WIP and you should review the resulting PR. God forbid someone comments on a change at the bottom of your commit chain, and you have to git rebase. I've messed this up a few times. I used to amend my commit chain to address PR feedback, but if you mess that up and force-push, you can't undo it because you lost history. You can make more commits, but if your PR has a non-trivial amount of feedback, the commit chain grows too long. Even worse, now people are reviewing commits that are stale because you've addressed things in subsequent commits! Stacked PRs solves reviewing with a reasonable user experience. I often need reviewers for different parts of the code. I can separate a larger change into a stack of 3-4 smaller changes, and each team can review their smaller section. People will easily approve a PR if they can review it within 5 minutes, and are willing to push up to 15 minutes. Anything that takes more time than that people will pass over. The review time is not proportional to size of PR. Larger PRs take WAY more time because there’s so much more jumping around and keeping things in mind with bigger PRs. Some stacks cannot be merged all at once, like a squash merge. For example, a DB migration or some infra changes may need to be merged and deployed before dependent changes can be merged and deployed. As such, you need to merge one PR and then another, but it's very helpful to have your top PR be fully testable so you know everything fits together nicely. The main flaw I see is that if you have to `git revert`, you might need to do so on a stack of merge commits instead of a single merge commit. Additionally, I have to be extra diligent at explaining that I'm using a stack of PRs that all tie together into a larger story, but that's just for the history. But the number of times I run into these “history” problems is extremely eclipsed by the number of times I need reviews on a PR. > — [markerz on lobsters · 5 points, 1 comments](https://lobste.rs/s/aj7msu/accepting_messy_git_history#c_qynixq) > I'm constantly looking at it -- usually, there are hints about why something is the way it is, and I need to understand that in order to know if a change I'm making sensible, or whether there's additional context I need to consider. It's very common that the weird behavior was done for a reason I hadn't considered, and I need to revise my changes to take it into account. > — [orib on lobsters · 8 points](https://lobste.rs/s/aj7msu/accepting_messy_git_history#c_1pglvy) > I would like to add to what kevincox said from my own work experience. I may be the only on my team using jj so my PRs are usually just one commit. The rest of team, using git, usually push from two to undetermined commits to the same PR; that's why, when merged to main, commits are automatically (i.e. forced) squashed. So, recently, we did a refactor to remove some legacy code. I took care of the front end, and had to restart the task a couple of times because once I finished, the tests would fail. Then I took another approach. First I removed some code that would not change functionality and see if it test passed; if so, I created a new jj change. By the moment I was ready to merge, I had three commits in which tests passed and the production site would not break. After my PR was merged, they noticed that we had to revert part of what I done. In an ideal world (or work), I could have checked main and reverted the specific commit, but since it was squashed, getting a usable diff was impossible (and also the commit modified hundred of mock test files). Thanks to some superior deity, my old commits were still in my original feature branch; they cherry picked my commits to create a new integration branch. So I sold my soul to an evil deity and told the AI, "Here you have the main branch and here's a git diff of a commit that was squashed. Untangle it to revert what that commit did". The AI managed to do the task and the PR was merged. So, the lesson is, never force squashing. > — [fedemp on lobsters · 1 points, 1 comments](https://lobste.rs/s/aj7msu/accepting_messy_git_history#c_ndf3np) > I tend not to look at the history too much, but other people at $WORK depend on it to a point that I didn’t really understand until I read the comments here. The thing is, when I build a system, it will be composed of a set of bounded contexts, [each] with a small number of very well defined interfaces, extremely low external coupling, minimal dependencies and relatively simple transformations. A side effect of this approach is that the code is reasonably stable over long periods of time and changes tend to be focussed and limited in scope. But I have recently inherited a bajillion lines of very tightly coupled spaghetti, and to my surprise, my new team often uses git to consider the “intent” of the developer when they made a change many years ago. Because the software itself is poorly organised, with lots of accidental complexity, git is effectively a database of similarly complex decisions over time. My point is that the dichotomy presented in this article really helped me to see this for the first time. I thought I was doing git wrong, because I haven’t needed this until now, but that’s maybe not the full story. I wonder if there is a connection between the complexity of the code base in a developer’s early years, and what they prefer. (As an aside, I think minimising accidental complexity is a much better use of time than years of trying to deal with it later, but it’s hard to do and even harder to explain) Edit: added [each] for clarity > — [doctor\_eval on lobsters · 2 points](https://lobste.rs/s/aj7msu/accepting_messy_git_history#c_6jpvad) > > I'm not sure about you folks, but I can count on a single palm how many times I actually looked at git history to understand the state of things. Usually I live with the code as it changes (doesn't matter if I did these changes or not). If I don't, then it might be too big to catch anyway. Okay. Well, I look at git blame at least once a week, and often more than that. It is very disappointing when I see projects wreck their history, especially in the LLM age when maintaining a clean history is easier than ever. > Plus, how much time back a git history is useful? 3 months, 3 years? Try 30 years? > — [sunshowers on lobsters · 6 points](https://lobste.rs/s/aj7msu/accepting_messy_git_history#c_bzjy59) **Source threads** - [lobsters](https://lobste.rs/s/aj7msu/accepting_messy_git_history) · 10 points · 21 comments ## Similar posts on daily.dev - [Git Commands For a Single Commit](https://daily.dev/posts/git-commands-for-a-single-commit-rbwx1zjhh) · Atomic Spin · 1 upvotes · 1 comments - [Git Rebase for the Terrified](https://daily.dev/posts/git-rebase-for-the-terrified-ynroja8em) · Hacker News · 1 upvotes · 0 comments - [GitHub Targets Large Merge Problem with Stacked PRs](https://daily.dev/posts/github-targets-large-merge-problem-with-stacked-prs-uurdnoxt2) · InfoQ · 2 upvotes · 0 comments - [Two regimes of Git](https://daily.dev/posts/two-regimes-of-git-p2epavg7b) · ploeh blog · 0 upvotes · 0 comments --- Tags: [#git](https://daily.dev/tags/git), [#version-control](https://daily.dev/tags/version-control) [View this post on daily.dev](https://daily.dev/posts/accepting-a-messy-git-history-96mlbskre) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Accepting a messy git history","url":"https://daily.dev/posts/accepting-a-messy-git-history-96mlbskre","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/accepting-a-messy-git-history-96mlbskre"},"datePublished":"2026-07-31T22:54:51.419Z","dateModified":"2026-08-03T15:46:16.049Z","description":"GitHub's stacked pull requests launch has reignited a long-standing debate between two camps of git users: those who commit often and embrace messy histories,...","image":"https://media.daily.dev/image/upload/s--foaA6JGU--/f_auto/v1722860399/public/Placeholder%2004","thumbnailUrl":"https://media.daily.dev/image/upload/s--foaA6JGU--/f_auto/v1722860399/public/Placeholder%2004","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/accepting-a-messy-git-history-96mlbskre","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"git,version-control","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Accepting a messy git history"}]} ```