8 ms·

Do people out there actually squash commits? Granted, I didn't change many work places in my career, but at no place where I worked people squashed commits. Wha

Do people out there actually squash commits? Granted, I didn't change many work places in my career, but at no place where I worked people squashed commits. What's even the point of it? It's not like people routinely read the commit history, and when they do, they really would like a complete story, not 20 gargantuan commits that contain 3 years of development.

rmrfrmrf 6y ago
depending on what im doing, i'll do squashing, fixups, and commit reordering in an interactive rebase prior to merging to at least reduce the number of noise commits.
aurelianito 6y ago
Yes they do. And it is frustrating. Specially frustrating when you ar the new guy and the history of the code does not tell what happened.
- eptcyka 6y ago
  I don't think having a history full of "Fix the shaver, maybe yaks don't need 6mm trim" with subsequent "Fix shaver again, yaks need as low as a 3mm trim" with some more intermediate commits help understanding what happened either.
  - janee 6y ago
    yep exactly this. I found early on while having to work with perforce and using timelapse view (git blame but with a nice gui) that lots of intermediary commits like this generate enough noise to discourage even the most determined sleuth from using commit history to solve a crime. Well scoped and well sized commits, squashed, and in my personal preference rebased, provide a commit history that's segregated on actual tickets/stories/features/fixes that I find are navigatable very far back. I'd say squash usage is very much case by case. But yeah equating a feature like squash to large commits is a fallacy. It's a useful tool imo that can be misused, but that doesn't mean the tool is "bad".
  - maccard 6y ago
    That's much better than looking at a file in a 300 file commit and seeing "merged from XXXX" with no information as to why that one line was changed. I'd much rather spend 30 seconds parsing through the 10 yak shaving commits than have to go trawling through old commits on a file to find the most likely owner of it to ping on slack.
    - OJFord 6y ago
      That's not what would happen though, by default the resulting commit message contains the messages from all those squashed into it.
    - saagarjha 6y ago
      You’re creating a false dichotomy. When people say “squash your commits”, the don’t mean “squash your entire repo into one commit”, they mean “get rid of you ‘typo’, ‘typo fix’ commits”. Your commits should still be small and self-contained.
      - maccard 6y ago
        Actually I think you're creating a false dichotomy. How many people are commiting dozens of "typo/fix build" commits and then squashing just those? In reality people are squashing the iteration process of "add an X, add a Y, remove the X because it didn't work, and add a Z instead of an X and Y" into "Add a Z" If you're simply talking about removing "fix typo" commits, then just don't. Just ignore them. You don't need them, but someone might. They're not hurting you?
        saagarjha 6y ago
        When that happens, I usually stick in a comment about it. Generally anything worth committing gets merged anyways so you still get the "Revert X" commit in there too.
- blandflakes 6y ago
  I feel like any discussion of squashing or not is only half the story - people need to write good commit messages. A lot of people I've worked with commit too granularly for that single commit to be useful, so squashing gets things grouped more usefully. However, if they still make low effort commit messages, then the history is useless. But it always was useless, squashed or not!
fs111 6y ago
I always squash my commits and at my current place that is even enforced via phabricator
- gray_-_wolf 6y ago
  You can always land with `--merge`. That is what I do if it actually makes sense to preserve individual commits.
- objclxt 6y ago
  Phabricator has a quite different (I would say better, others would say worse) development flow philosophy to GitHub/PRs. Phabricator’s preferred model, which is heavily influenced by Facebook, is to forgo feature branches entirely and just stack many small changes on top of each other, landing as and when you want (this doesn’t preclude you working on feature branches locally, of course, because Phabricator doesn’t care what your local checkout looks like). Because of this, Phabricator considers each diff to be discrete, and if you have multiple changes making up a single feature they should in turn be broken down into separate diffs. Personally, I think stacked diffs are the killer feature of Phabricator. Unfortunately I haven’t been able to find a similar flow with PRs (recently we migrated from Phabricator to GitHub for one of my projects), you end up fighting against the tool a lot.
  - ericyu3 6y ago
    Stacked diffs have been a pain for me as well, but recently I found a tool that makes it super easy to implement stacked diffs on top of GitHub! I started using it a month ago and it makes complex code changes so much easier to split up into manageable chunks. It's called ghstack (https://github.com/ezyang/ghstack https://github.com/ezyang/ghstack) If you want to learn more you can email me at ericyu3@gmail.com. Also happy to help you get it up and running - just put some time on my calendar at https://calendly.com/ericyu3/15min https://calendly.com/ericyu3/15min
Kihashi 6y ago
I find the individual commits on feature branches to be more noise than signal after they are merged. They can be useful during review, sometimes, but mostly I want a cleaner history. > they really would like a complete story, not 20 gargantuan commits that contain 3 years of development That sounds like maybe we split up work differently. 3 years of development for me or my team would likely have hundreds+ of merge/squash commits, not 20 large ones.
- pbalau 6y ago
  If you look at the PRs list, you will have a clean and tidy history.
  - alkonaut 6y ago
    Yep, but many tools (most notoriously git bisect, famous from the article) doesn't understand "--first-parent" which is ridiculous. The only way to have a clean history that all tools accept is clean, is basically to outlaw merges.
- mcny 6y ago
  > That sounds like maybe we split up work differently. 3 years of development for me or my team would likely have hundreds+ of merge/squash commits, not 20 large ones. With the people I've worked with, I'd say most don't commit at all until they think the code is "ready" and they commit all at once. In the teams I've worked with, squashing vs not squashing isn't the question. I just want them to commit/push as soon as they've hit a stopping point or at least once a day. Maybe the people you've worked with are good with git but I am not that good with git. I'm still stuck on 6: Resolve a merge conflict on git exercises because I made one too many commits and now the exercise says I have too many commits. https://gitexercises.fracz.com/ https://gitexercises.fracz.com/ Previously on HN: https://news.ycombinator.com/item?id=24671638 https://news.ycombinator.com/item?id=24671638
  - mkesper 6y ago
    You need to squash your commits, then: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
FeepingCreature 6y ago
I squash commits. Well, I rebase so that changes are logical rather than historical. This is because when people read the commit history, which actually happens regularly, they would actually like a complete story, not 15 commits of "fix audit", "fix review" and "fix typo" - let alone refactors where previous work in the PR is thrown out, which you can by definition never care about. Commits so small that they're nonfunctional also break bisect.
- twic 6y ago
  Nobody is suggesting you should make commits so small they're non-functional.
  - xorcist 6y ago
    Are you simply suggesting the removal of those non-functional commits to be called something else than "squashing"?
    - twic 6y ago
      I'm suggesting you don't make them in the first place. If you do make them by mistake - and everyone does sometimes, certainly including me - then sure, commit --amend or squash them before pushing them up. The squashing the article is talking about is collapsing functional, distinct commits into one when merging to the trunk. It would be useful if we had distinct terms for the two kinds of squashing; the git command commit --fixup and its associated interactive rebase operation suggest the name "fixups".
      - xorcist 6y ago
        The difference between fixups and squashing is only in how the commit message is generated. Both are (interactive) rebase operations. Both are established terms in git, and it is probably not very useful to change that nomenclature now.
        6y ago
s_dev 6y ago
>Do people out there actually squash commits? Depedends on the git flow being adopted by the commiters. HNers constantly espouse how clarity is more important than cleverness. It may be the case that a single commit offers more concision than multiple commits which could be perceived as just more noise.
ZephyrBlu 6y ago
At my workplace we generate ~150 commits every week or two. There are a lot of trash commits and the history is completely unreadable. I'm sure that's barely any compared to large companies, so I really question the value of commit history unless message guidelines are well enforced.
- maccard 6y ago
  We go through ~600 commits per day. In my experience, there's nothing worse than looking for when a value was changed from 10 to 100, and finding it in a "Merged from X" commit with the history of why the value was changed from 10 to 100. I don't often (ever?) browse the history, but I _do_ regularly search the history using tooling, (git log | grep <something>), and more is more in that case, even if the history isn't perfect.
  - saagarjha 6y ago
    That just sounds like a bad squash.
    - maccard 6y ago
      If the original commits are: - Change X to 10 by Foo - Change X to 100 by Bar - Change X to 50 by Baz And that gets squashed into `Change X to 50 by Baz`, you lose the context as to why Foo and Bar changed it, and the values. If I need to go investigate an issue with X, I'd rather thave the history of all the changes.
      - saagarjha 6y ago
        Commits by multiple people should rarely, if ever, be squashed.
ChrisMarshallNY 6y ago
I squash, but it's not something I do regularly. In my case, it's generally because I'm preparing training material. When I do that, I have two branches: dev and master. master is the one that is exposed to students, and dev is the one I use for prepping, testing and staging. Sometimes, I may even have the dev branch in a private repo, or one that is associated with a different GH ID, like so: https://24ways.org/2013/keeping-parts-of-your-codebase-private-on-github/ https://24ways.org/2013/keeping-parts-of-your-codebase-priva... The main "gotcha" for me, is to make sure that I merge the master back into dev, after doing the squash. Makes life a lot easier, for the next squash.
flohofwoe 6y ago
I squash commits on large PRs on a case-by-case basis, especially when they have a lot of very small and silly commits (fix this, fix that, wip, ...) but implement a very specific feature which required a lot of experiments that didn't end up in the final PR. And yes, I use the commit history very frequently, so it's important for me that this doesn't contain too much noise. If I need to bisect a bug that was introduced by the PR I still can do this in the original branch.
- dmatech 6y ago
  Ideally, that would give you the best of both worlds. But some places delete the old branches after they're merged. It would be nice if there were an easy way to hide or rename old branches so that the in-use ones stand out.
stepsrabbit 6y ago
If you always work in feature branches and commit often (which you should IMO) it makes perfect sense to squash on merge. It gives you a nice history that only contains relevant commits instead of having a bunch of “added tests”/“fixed XYZ”/“remove debug log”/etc commits. With some discipline this makes the commit history actually worth reading and makes git blame a useful tool.
SXX 6y ago
I guess It's my development culture is flawed, but as one-man-team I always time constrained. So I sometimes don't have sufficient time to write too detailed commit messages. So I end up with "one commit per feature" rather than "one commit per logical change". So I actively using squash during interactive rebase when I prepare to merge completed branch since my commit history sometimes looks like this: Backend: new set of APIs for XYZ Backend: implement feature X (+ some long comment) Frontend: implement feature X fix for feature backend fix for backend API XYZ front fix backend fix Yeah again I know I could do better, but yeah I use squashing for this reason. A lot.
- Joker_vD 6y ago
  Well, uh, yes, that's what the commit history generally looks like (although we do generally put "JIRA-9999: " in front of all commit messages, for context). So what?
  - SXX 6y ago
    What I wanted to say that since I don't have that many people other than me looking into my code there no reason to preserve real development history of every feature and IMO 3 "feature commits" are preferable than my development mess of 50 "fix that fix this" commits.
np_tedious 6y ago
The argument for squashing is that minor updates like spelling, renaming, or test fixes during initial development can really clutter the history if they each have a commit. Many would rather see the actual change "Update X to use Y instead of Z" in the history, and minor details like "Fix mock in XTestCase" or "Perform renames from code review" within that single commit. I'm sort of agnostic on this issue, but I do feel the article's author kind of overstated it here. Say 5 to 10 commits of this size were squashed together. Git bisect would've taken him 90+% as far and he'd have to read code or manually trial and error changes just slightly more. The binary searchable problem space would be slightly smaller, and the linear manual effort space slightly bigger. Less good, but really not that big of a deal.
- twic 6y ago
  For me, it's the other way round: minor updates like spelling, renaming, or test fixes during initial development can really clutter the major updates. If i am making a commit that makes a complex but important change to some significant application logic, i want that commit to contain that change and only that change, so that when i have to re-read it a year later, it's completely obvious what i did and why. Bundling a load of refactoring and cleanup in there is a significant speedbump for my understanding. Years ago, a sage pointed out the argument for squashing is really an argument for better tools. Imagine if you could flag commits as being of two types - major/minor, significant/insignificant, feature/refactoring, foreground/background, melody/rhythm, etc. Then imagine if the tools would by default hide, roll up, or otherwise de-emphasise the commits of the latter kind. This whole apparent dichotomy would go away in a flash. This idea is floating around in the Wiki world. I believe it was Ward's Wiki that introduced a 'minor edit' checkbox in the editor; if a change was marked as a minor edit, it wouldn't be show on the recent changes feed. You can imagine other ways to get somewhere similar. For example, you could have a special kind of commit that just groups a previous run of commits, and the tools could show that and hide the members of the group by default. There are probably many other ways to do this.
  - tasogare 6y ago
    Interesting idea, however this could also be easily abused for nefarious use.
jdmoreira 6y ago
I religiously squash my commits for each merged pull request. I seems like madness any other way to me... why have a bigger granularity than a single merge commit?
- adrianN 6y ago
  Granularity helps with bisecting issues.
  - bJGVygG7MQVF8c 6y ago
    Yes. But also: Granularity undermines the effectiveness of bisecting when your commits aren't ACID. These conversations are so often tedious and repetitive largely because engineers seem incapable or unwilling to apply systems thinking to development practices.
  - jdmoreira 6y ago
    at least in github after you find the squash commit equivalent to the PR you can restore the branch and bisect the rest in there. This is much faster!
- DougBTX 6y ago
  Interesting, it seems like madness to me to have it the other way around. Why bother with a merge commit if all the changes are squashed into one anyway? Why not just fast forward merge as if it was a commit directly to the main development branch?
swalsh 6y ago
I do, all the time. I highly recommend others do it too. I like to keep to 1 commit per ticket (even a super large ticket that might take me weeks of development). But having a commit history like the fella in this story is nice too. So what you should do is work in a feature branch. On the day of deployment I'll squash, and cherry pick (in my case to a train). If the deployment goes bad, and my code is at fault, then all that is required to fix it is a single revert. If you want to continously deploy to production (with real users using it) you need a process to very quickly revert bad commits from it. At my last company with hundreds of developers, we would push to prod several times a day. Each deployment would have several devs changes included. A clean linear history is essential to making that process work.
- Joker_vD 6y ago
  Wait, I must be missing something. I too develop in feature branches, and then they're merged into develop or main (with a merge commit, obviously). Reverting that is too only a single revert. The only problem is that sooner or late those feature branch do get deleted, and if you swashed, you lose all the non-squashed history. If you don't, it's still in the develop/main branch. What do I miss?
- mfontani 6y ago
  You get a similar benefit (a single revert to revert it all) via "git merge --no-ff BRANCH". If the BRANCH is a fast-forward (i.e. it's been rebased to master/main & tested before merge) then you get both benefits of a clean history and an easy revert, for little downside. Keeping the history of each incremental change, even in a branch, is IMO too useful to give up. Note I'm not advocating keeping those "fixed typo in previous commit" fix-up commits: those should be properly fixed up _before_ merge, by judicious use of git rebase.
lordnacho 6y ago
The only time I ever do it is if it's trivial. Say I've removed some vestigial code, then I find some more after I've committed.
aequitas 6y ago
Depends on the Git craftmanship of the team is my experience. If they commit every small fix with a useless commit message, history becomes messy real quick. Squashing can be seen as a solution here. Until you learn proper rewriting of history as in (interactive) rebasing. After which you can put you code changes in every commit you want and order them around as you see fit. But that also depends on the Git workflow that is used and how much branches are shared amongst team members. I had one job in the past that used Gerrit[0] as Git tool. One of it's features is that it creates a "pullrequest" for every commit in the branch you push. Which needs to be reviewed individually. This is really anoying if you're used to organising your work in lot of commits to record each step of your developerment. But from a project's Git history perspective it makes a lot of sense. As every commit is 1 change, one feature, one contained unit, that is added to the main branch. So instead of the main branch now containing countless commits with each developers complete history on a specific feature (where code is added in one commit to be removed in the next) it contains the features as distict commits, making them easy to bisect and revert if needed. This looks a lot like squashing but because you do it before you push your code you learn to put much more thought into that single commit and the commit message. [0] https://www.gerritcodereview.com/ https://www.gerritcodereview.com/
saurik 6y ago
I think what you really want is neither of squashing nor retaining: what you want is to take the messy history you had and then reconstruct a history that makes sense and commit that; thankfully, git makes this easy. I hate it when people leave messy thoughts in the commit history as I do use the history, and it is even worse if they just leave mega-commits. I want to see easy to review step by step organized thoughts designed to help the reader appreciate the series of steps needed to bring you from where you were to where you went.
- twic 6y ago
  I would say the best thing is to cultivate the habit of thinking and working cleanly, so you create a history of small, logical, incremental commits. But the second best thing is to think and work messily, and use rebasing to fake a history of small, logical, incremental commits!
simias 6y ago
I often do intermediary commits that don't compile or break something significant, only to make sure that I don't lose the code. When that happens I always squash my commit afterwards once the code is in a usable state. The alternative is making bisecting harder which is not something that I want. I want every commit to compile and be testable individually. That definitely doesn't mean that I think it's a good idea to have "gargantuan" commits. An ideal commit should contain a single, atomic change to the codebase. Not more, but also not less.
- rutthenut 6y ago
  I'm a bit confused on your comments here. You state "I often do intermediary commits that don't compile ... to make sure that I don't lose the code" And follow that with "I want every commit to compile and be testable individually."
  - simias 6y ago
    I mean that I do many small "crap" commits while developing, once I'm ready to merge into the main branch I clean the history to get proper, atomic commits.
  - StanLindsey 6y ago
    I'm the same as OP. I commit constantly when hitting a natural stop point or when taking a break and push up to my branch/pr. I hate having code locally that hasn't been pushed to the origin. But doing this means I have many commits that don't mean anything or are unfinished and in an uncompilable state. So I git rebase and massage the history to make more sense.
clinta 6y ago
Everyone who works on Linux must rebase and squash commits so that every commit builds and passes tests, and does a single thing. More about how Linux uses git: https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html https://www.mail-archive.com/dri-devel@lists.sourceforge.net... https://www.linux.com/news/why-linuxs-biggest-ever-kernel-release-is-really-no-big-deal/ https://www.linux.com/news/why-linuxs-biggest-ever-kernel-re...
alkonaut 6y ago
You don't have to squash into ONE commit just because you squash. If I make 10 commits I can squash it into two logical commits (e.g. refactor, add feature) then I merge the branch with those two. If the branch is small and has 3 commits that are one logical change, then I might as well squash to main instead of merging. Commit history is readable regardless (I'd never use anything but --first-parent ever).
mcv 6y ago
I do read the git commit history, and specifically to find problems like these. Squashing commits indeed sounds like a terrible idea to me. There are also people who insist you always need to rebase your commits before pushing, in order to get a nice, linear history, and again I disagree. It's fine when you're rebasing a very short (single commit) history, but for a long history, it not only gets very tedious, but when it introduces new bugs halfway through that history, you may not notice. You will notice later, and then tracking that bug you end up in the middle of your own (rebased) history and you may wonder why you ever did something so stupid, when the actual cause of the bug was the merge of two histories at the end of your work. I do rebase sometimes, but only when the history is short and I can easily see what I'm rebasing. A history longer than 2 commits should not be changed. I never squash.
reallydontask 6y ago
From experience of working with new CI/CD systems where one doesn't quite understand what's failing due to ... reasons. It's really quite easy to get into the 50s or close to 100 commits in a branch, which can lead to a horrendously messy history. There are also people that like to commit before the try something locally and their branches are effectively a mess. All of the above is magnified in a monorepo environment, where you might have thousands of commits a day against master if it weren't for enforcement policies that force a squash.
timvdalen 6y ago
It depends on the situation. If I'm merging a feature branch that has a lot of commits that effectively make up one feature (because a dev had to go back and forth or because there was a lot of feedback), I might squash those commits into one before I merge it into master. As mentioned elsewhere in the comments here, that also makes it a lot easier to revert said feature if something goes wrong.
3np 6y ago
Routinely. Common example that I can't see why anyone would take issue with: * Commit 1: Fix a bug * Commit 2: Fix linting issues with the fix discovered through CI * Commit 3: Remove dead/commented code introduced thrugh commit 1 * Commit 4: Update documents as required by change I'd always squash those into a single commit before merging into upstream.
- asveikau 6y ago
  I can see a good case for separating #2 from everything else. Or depending on the change, maybe squashing #2 and #3 together separate from 1 and 4. It's a good idea to isolate the bugfix so that reading the diff is clear. Stylistic changes such as #2 and #3 can be separated and called out as "should produce no behavior change" sort of updates.
ratww 6y ago
Squashing is kind a blunt tool that is useful sometimes, but can be perfectly replaced either by crafting your commits with more care or doing interactive rebasing. I once had to enforce to an developer that wanted to make 20 commits per PR that were titled like "wip" "wip" "wip" "fix bug" "fix mistake" "format code" in a PR that only changed like 10 lines of code in the end. In this case, the main problem for me was that git blame became useless because this developer was touching way more lines than necessary and then undoing it using the code formatter.
rjkennedy98 6y ago
Yes, our company squashes commits (we have tens or probably hundreds of thousands on the main branch). Yes, I routinely look at commit history. Commit history is also used for doing analytics for performance reviews such as how many commits did you make, what percentage had tests ect. For instance my last performance review made note that I had test coverage on 90% of my commits. Also, we auto-stamp the PR on the commits so we can get the context. I don't understand how anyone could make sense of a large codebase when all the commits are added with the standard inane commit messages (e.g. "fix it", "typo", "name changes", "tests") that people do when building a feature. I routinely have to look at a piece of code, do a git blame, get the PR in the commit and figure out what was being done.
CGamesPlay 6y ago
I'm probably 75/25 on this. 75% of the time I'm gonna squash, because my entire commit messages is along the lines of "got to this point" or "fix frotzolate when x=7". 25% of the time my first round of squashing yields good commit messages that are isolated and complete, so it's better to leave those as separate commits when merging into the mainline. I also aggressively reorder my commits. When it gets to yak shaving you basically develop in a stack, so you end up with a half-functional commit to system A at the top, then a complete commit to system B, then the finishing commit to system A, so it's better to just rearrange it so that you have one system B commit followed by one system A commit. But I do routinely read the commit history (using git blame) and no I don't want to see the "complete story" of my past self having "got to this point"--I want the documented MR commentary.
__s 6y ago
We do. PRs are generally smaller than 3 years of development. Sometimes refactoring will be split out so what could be a single PR with multiple commits instead becomes multiple PRs. This allows review to be focused on each PR & enforces that each commit maintain CI passing
UK-Al05 6y ago
# Implement feature # Whoops fixed issue in feature i just implemented # Add in whitespace # Remove whitespace # Forgot place to add in whitespace # Fix variable name for feature Vs # Implemented feature "x" Which ones easier to rollback and read.
chousuke 6y ago
Personally I think of working in a branch as the process of creating a patch set. A patch in a series should only depend on its predecessors. You can submit more than one patch in a pull request. I would never send out a patch set for review that includes all the "oops" "typo" "iteration 50" etc. commits I make as I work on code. Those are pure noise. However, git is a tool for development, and during development I should be able to use git in whichever way is convenient for me: commit, rewrite and do whatever the hell I want with my local history. Not having that freedom is the primary reason why working with most non-distributed version control systems is such a pain. When it comes to actually merging patch series to master, I like not doing fast-forward merges, since you maintain a natural grouping of the applied changes.
DrBazza 6y ago
> Do people out there actually squash commits? Yes, squashing parts of a discrete piece of work together, where it makes sense, then makes it trivial to git bisect any future problems. Code committed to the mainline should always compile, and should be made of discrete changes. However, do what you like on your unpublished local branch. > What's even the point of it? It's not like people routinely read the commit history, and when they do, they really would like a complete story, not 20 gargantuan commits that contain 3 years of development. My company routinely reads the commit history. The commit is usually the 'why', and the code is the 'how'.
Vinnl 6y ago
Yes I do (well, I rebase, not squash blindly), but I do read the commit history. Or well, not so much the complete history, but I do go looking for which commit introduced a particular line, what message went with that change, and what else changed with it. Of course, that only works after you leave proper commits. The reason people don't do that is because you only look at your commit history if you've kept it useful, but if you've never looked at your commit history because it's not, you don't know the benefits of keeping it useful.
vonmoltke 6y ago
It really depends on where you work and how your company's repo is organized. For instance, where I work 20 squash commits would represent, at most, 10 minutes worth of commits to the monorepo. Not squashing on merge would quickly turn thousands of daily commits into tens of thousands. It's already impractical to find suspect commits via git, and we typically use our code review tool to find the change that broke something (and that change includes the developer's full branch history). Adding more commits would needlessly slow down the tooling that displays 'git blame' results (and likely other commands). I suspect there is a pattern in the comments here. People who work on small teams with granular repos that, individually, don't see a lot of daily activity think squashing is bad and erases valuable history. People who work with large repos that see high commit velocity (like a monorepo) think squashing (at least merge squashing) is beneficial and don't see the loss of information as problematic because it's hard to access it in the first place. Maybe I'm just projecting my own opinions on this; I'd like to hear perspectives that conflict with my assumptions.
- spdionis 6y ago
  You are definitely correct. People who argue against squashing have not worked on 10+ years old actively developed repositories, or in big enough teams. A commit is a change. A change has a ticket. A ticket is a small piece of work that does not result in 3k changed lines. This ensures that the change rationale is fully documented and easily identifiable. Nobody needs those "fixed typo" commits. Nor the "implemented function A" commits. What IS the change that you're doing? What functionality? That's the most comfortable commit granularity to debug imho.
  - mixmastamyk 6y ago
    Agreed, I regularly add comments later as well. Understanding often comes after the code works. I could obsessively fiddle with every commit like an artesenal snowflake, or I could click the squash checkbox on the request.
mixmastamyk 6y ago
That's not how it works, really. A simplified workflow: You take bug or enhancement of a couple of points, work on it on its own branch, then merge req+squash the mostly noise commits into a develop/master at once. A chunk is approximately 3 days, not 3 years. For forward-looking projects, it saves time and works well. "Enterprisey" projects maintaining legacy branches are less well served.
kelnos 6y ago
It's a mix where I work. Most people aren't at all tidy with their commit history, and I'll often see a PR with a fairly small final diff (maybe a couple hundred lines changed total) with several useless one-word commit messages like "fix". And then after the PR has gone through review, most people tack on extra commits with equally-useless commit messages like "addressing feedback". It's infrequent that I see PRs with commit histories that actually chronicle the history of the change itself; it's more a chronicle of the developer's changing thought processes as they try different things, go down blind alleys, change approaches several times. Most of the individual commits have test suite failures and some of them don't even compile, so it's impossible to bisect across them if an issue is later found. In those cases, I wish people would just squash (and some do, where I work). Yes, you lose information and separation, but I'd rather have one large working commit than 15 small broken commits followed by one working commit. Ideally people would curate things before submitting their PR, but I've found that most people just don't care, or don't understand git well enough to even attempt to do it. Sometimes I toy around with the idea of trying to teach people (what I consider) better practices, and insist they are followed, but we all have a limited amount of social capital in our workplaces, and I'm not convinced this is something worth spending it on.

rmrfrmrf 6y ago

depending on what im doing, i'll do squashing, fixups, and commit reordering in an interactive rebase prior to merging to at least reduce the number of noise commits.

aurelianito 6y ago

Yes they do. And it is frustrating. Specially frustrating when you ar the new guy and the history of the code does not tell what happened.

eptcyka 6y ago
I don't think having a history full of "Fix the shaver, maybe yaks don't need 6mm trim" with subsequent "Fix shaver again, yaks need as low as a 3mm trim" with some more intermediate commits help understanding what happened either.
- janee 6y ago
  yep exactly this. I found early on while having to work with perforce and using timelapse view (git blame but with a nice gui) that lots of intermediary commits like this generate enough noise to discourage even the most determined sleuth from using commit history to solve a crime. Well scoped and well sized commits, squashed, and in my personal preference rebased, provide a commit history that's segregated on actual tickets/stories/features/fixes that I find are navigatable very far back. I'd say squash usage is very much case by case. But yeah equating a feature like squash to large commits is a fallacy. It's a useful tool imo that can be misused, but that doesn't mean the tool is "bad".
- maccard 6y ago
  That's much better than looking at a file in a 300 file commit and seeing "merged from XXXX" with no information as to why that one line was changed. I'd much rather spend 30 seconds parsing through the 10 yak shaving commits than have to go trawling through old commits on a file to find the most likely owner of it to ping on slack.
  - OJFord 6y ago
    That's not what would happen though, by default the resulting commit message contains the messages from all those squashed into it.
  - saagarjha 6y ago
    You’re creating a false dichotomy. When people say “squash your commits”, the don’t mean “squash your entire repo into one commit”, they mean “get rid of you ‘typo’, ‘typo fix’ commits”. Your commits should still be small and self-contained.
    - maccard 6y ago
      Actually I think you're creating a false dichotomy. How many people are commiting dozens of "typo/fix build" commits and then squashing just those? In reality people are squashing the iteration process of "add an X, add a Y, remove the X because it didn't work, and add a Z instead of an X and Y" into "Add a Z" If you're simply talking about removing "fix typo" commits, then just don't. Just ignore them. You don't need them, but someone might. They're not hurting you?
      - saagarjha 6y ago
        When that happens, I usually stick in a comment about it. Generally anything worth committing gets merged anyways so you still get the "Revert X" commit in there too.
blandflakes 6y ago
I feel like any discussion of squashing or not is only half the story - people need to write good commit messages. A lot of people I've worked with commit too granularly for that single commit to be useful, so squashing gets things grouped more usefully. However, if they still make low effort commit messages, then the history is useless. But it always was useless, squashed or not!

fs111 6y ago

I always squash my commits and at my current place that is even enforced via phabricator

gray_-_wolf 6y ago
You can always land with `--merge`. That is what I do if it actually makes sense to preserve individual commits.
objclxt 6y ago
Phabricator has a quite different (I would say better, others would say worse) development flow philosophy to GitHub/PRs. Phabricator’s preferred model, which is heavily influenced by Facebook, is to forgo feature branches entirely and just stack many small changes on top of each other, landing as and when you want (this doesn’t preclude you working on feature branches locally, of course, because Phabricator doesn’t care what your local checkout looks like). Because of this, Phabricator considers each diff to be discrete, and if you have multiple changes making up a single feature they should in turn be broken down into separate diffs. Personally, I think stacked diffs are the killer feature of Phabricator. Unfortunately I haven’t been able to find a similar flow with PRs (recently we migrated from Phabricator to GitHub for one of my projects), you end up fighting against the tool a lot.
- ericyu3 6y ago
  Stacked diffs have been a pain for me as well, but recently I found a tool that makes it super easy to implement stacked diffs on top of GitHub! I started using it a month ago and it makes complex code changes so much easier to split up into manageable chunks. It's called ghstack (https://github.com/ezyang/ghstack https://github.com/ezyang/ghstack) If you want to learn more you can email me at ericyu3@gmail.com. Also happy to help you get it up and running - just put some time on my calendar at https://calendly.com/ericyu3/15min https://calendly.com/ericyu3/15min

Kihashi 6y ago

I find the individual commits on feature branches to be more noise than signal after they are merged. They can be useful during review, sometimes, but mostly I want a cleaner history. > they really would like a complete story, not 20 gargantuan commits that contain 3 years of development That sounds like maybe we split up work differently. 3 years of development for me or my team would likely have hundreds+ of merge/squash commits, not 20 large ones.

pbalau 6y ago
If you look at the PRs list, you will have a clean and tidy history.
- alkonaut 6y ago
  Yep, but many tools (most notoriously git bisect, famous from the article) doesn't understand "--first-parent" which is ridiculous. The only way to have a clean history that all tools accept is clean, is basically to outlaw merges.
mcny 6y ago
> That sounds like maybe we split up work differently. 3 years of development for me or my team would likely have hundreds+ of merge/squash commits, not 20 large ones. With the people I've worked with, I'd say most don't commit at all until they think the code is "ready" and they commit all at once. In the teams I've worked with, squashing vs not squashing isn't the question. I just want them to commit/push as soon as they've hit a stopping point or at least once a day. Maybe the people you've worked with are good with git but I am not that good with git. I'm still stuck on 6: Resolve a merge conflict on git exercises because I made one too many commits and now the exercise says I have too many commits. https://gitexercises.fracz.com/ https://gitexercises.fracz.com/ Previously on HN: https://news.ycombinator.com/item?id=24671638 https://news.ycombinator.com/item?id=24671638
- mkesper 6y ago
  You need to squash your commits, then: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

FeepingCreature 6y ago

I squash commits. Well, I rebase so that changes are logical rather than historical. This is because when people read the commit history, which actually happens regularly, they would actually like a complete story, not 15 commits of "fix audit", "fix review" and "fix typo" - let alone refactors where previous work in the PR is thrown out, which you can by definition never care about. Commits so small that they're nonfunctional also break bisect.

twic 6y ago
Nobody is suggesting you should make commits so small they're non-functional.
- xorcist 6y ago
  Are you simply suggesting the removal of those non-functional commits to be called something else than "squashing"?
  - twic 6y ago
    I'm suggesting you don't make them in the first place. If you do make them by mistake - and everyone does sometimes, certainly including me - then sure, commit --amend or squash them before pushing them up. The squashing the article is talking about is collapsing functional, distinct commits into one when merging to the trunk. It would be useful if we had distinct terms for the two kinds of squashing; the git command commit --fixup and its associated interactive rebase operation suggest the name "fixups".
    - xorcist 6y ago
      The difference between fixups and squashing is only in how the commit message is generated. Both are (interactive) rebase operations. Both are established terms in git, and it is probably not very useful to change that nomenclature now.
      - 6y ago

s_dev 6y ago

>Do people out there actually squash commits? Depedends on the git flow being adopted by the commiters. HNers constantly espouse how clarity is more important than cleverness. It may be the case that a single commit offers more concision than multiple commits which could be perceived as just more noise.

ZephyrBlu 6y ago

At my workplace we generate ~150 commits every week or two. There are a lot of trash commits and the history is completely unreadable. I'm sure that's barely any compared to large companies, so I really question the value of commit history unless message guidelines are well enforced.

maccard 6y ago
We go through ~600 commits per day. In my experience, there's nothing worse than looking for when a value was changed from 10 to 100, and finding it in a "Merged from X" commit with the history of why the value was changed from 10 to 100. I don't often (ever?) browse the history, but I _do_ regularly search the history using tooling, (git log | grep <something>), and more is more in that case, even if the history isn't perfect.
- saagarjha 6y ago
  That just sounds like a bad squash.
  - maccard 6y ago
    If the original commits are: - Change X to 10 by Foo - Change X to 100 by Bar - Change X to 50 by Baz And that gets squashed into `Change X to 50 by Baz`, you lose the context as to why Foo and Bar changed it, and the values. If I need to go investigate an issue with X, I'd rather thave the history of all the changes.
    - saagarjha 6y ago
      Commits by multiple people should rarely, if ever, be squashed.

ChrisMarshallNY 6y ago

I squash, but it's not something I do regularly. In my case, it's generally because I'm preparing training material. When I do that, I have two branches: dev and master. master is the one that is exposed to students, and dev is the one I use for prepping, testing and staging. Sometimes, I may even have the dev branch in a private repo, or one that is associated with a different GH ID, like so: https://24ways.org/2013/keeping-parts-of-your-codebase-private-on-github/ https://24ways.org/2013/keeping-parts-of-your-codebase-priva... The main "gotcha" for me, is to make sure that I merge the master back into dev, after doing the squash. Makes life a lot easier, for the next squash.

flohofwoe 6y ago

I squash commits on large PRs on a case-by-case basis, especially when they have a lot of very small and silly commits (fix this, fix that, wip, ...) but implement a very specific feature which required a lot of experiments that didn't end up in the final PR. And yes, I use the commit history very frequently, so it's important for me that this doesn't contain too much noise. If I need to bisect a bug that was introduced by the PR I still can do this in the original branch.

dmatech 6y ago
Ideally, that would give you the best of both worlds. But some places delete the old branches after they're merged. It would be nice if there were an easy way to hide or rename old branches so that the in-use ones stand out.

stepsrabbit 6y ago

If you always work in feature branches and commit often (which you should IMO) it makes perfect sense to squash on merge. It gives you a nice history that only contains relevant commits instead of having a bunch of “added tests”/“fixed XYZ”/“remove debug log”/etc commits. With some discipline this makes the commit history actually worth reading and makes git blame a useful tool.

SXX 6y ago

I guess It's my development culture is flawed, but as one-man-team I always time constrained. So I sometimes don't have sufficient time to write too detailed commit messages. So I end up with "one commit per feature" rather than "one commit per logical change". So I actively using squash during interactive rebase when I prepare to merge completed branch since my commit history sometimes looks like this: Backend: new set of APIs for XYZ Backend: implement feature X (+ some long comment) Frontend: implement feature X fix for feature backend fix for backend API XYZ front fix backend fix Yeah again I know I could do better, but yeah I use squashing for this reason. A lot.

Joker_vD 6y ago
Well, uh, yes, that's what the commit history generally looks like (although we do generally put "JIRA-9999: " in front of all commit messages, for context). So what?
- SXX 6y ago
  What I wanted to say that since I don't have that many people other than me looking into my code there no reason to preserve real development history of every feature and IMO 3 "feature commits" are preferable than my development mess of 50 "fix that fix this" commits.

np_tedious 6y ago

The argument for squashing is that minor updates like spelling, renaming, or test fixes during initial development can really clutter the history if they each have a commit. Many would rather see the actual change "Update X to use Y instead of Z" in the history, and minor details like "Fix mock in XTestCase" or "Perform renames from code review" within that single commit. I'm sort of agnostic on this issue, but I do feel the article's author kind of overstated it here. Say 5 to 10 commits of this size were squashed together. Git bisect would've taken him 90+% as far and he'd have to read code or manually trial and error changes just slightly more. The binary searchable problem space would be slightly smaller, and the linear manual effort space slightly bigger. Less good, but really not that big of a deal.

twic 6y ago
For me, it's the other way round: minor updates like spelling, renaming, or test fixes during initial development can really clutter the major updates. If i am making a commit that makes a complex but important change to some significant application logic, i want that commit to contain that change and only that change, so that when i have to re-read it a year later, it's completely obvious what i did and why. Bundling a load of refactoring and cleanup in there is a significant speedbump for my understanding. Years ago, a sage pointed out the argument for squashing is really an argument for better tools. Imagine if you could flag commits as being of two types - major/minor, significant/insignificant, feature/refactoring, foreground/background, melody/rhythm, etc. Then imagine if the tools would by default hide, roll up, or otherwise de-emphasise the commits of the latter kind. This whole apparent dichotomy would go away in a flash. This idea is floating around in the Wiki world. I believe it was Ward's Wiki that introduced a 'minor edit' checkbox in the editor; if a change was marked as a minor edit, it wouldn't be show on the recent changes feed. You can imagine other ways to get somewhere similar. For example, you could have a special kind of commit that just groups a previous run of commits, and the tools could show that and hide the members of the group by default. There are probably many other ways to do this.
- tasogare 6y ago
  Interesting idea, however this could also be easily abused for nefarious use.

jdmoreira 6y ago

I religiously squash my commits for each merged pull request. I seems like madness any other way to me... why have a bigger granularity than a single merge commit?

adrianN 6y ago
Granularity helps with bisecting issues.
- bJGVygG7MQVF8c 6y ago
  Yes. But also: Granularity undermines the effectiveness of bisecting when your commits aren't ACID. These conversations are so often tedious and repetitive largely because engineers seem incapable or unwilling to apply systems thinking to development practices.
- jdmoreira 6y ago
  at least in github after you find the squash commit equivalent to the PR you can restore the branch and bisect the rest in there. This is much faster!
DougBTX 6y ago
Interesting, it seems like madness to me to have it the other way around. Why bother with a merge commit if all the changes are squashed into one anyway? Why not just fast forward merge as if it was a commit directly to the main development branch?

swalsh 6y ago

I do, all the time. I highly recommend others do it too. I like to keep to 1 commit per ticket (even a super large ticket that might take me weeks of development). But having a commit history like the fella in this story is nice too. So what you should do is work in a feature branch. On the day of deployment I'll squash, and cherry pick (in my case to a train). If the deployment goes bad, and my code is at fault, then all that is required to fix it is a single revert. If you want to continously deploy to production (with real users using it) you need a process to very quickly revert bad commits from it. At my last company with hundreds of developers, we would push to prod several times a day. Each deployment would have several devs changes included. A clean linear history is essential to making that process work.

Joker_vD 6y ago
Wait, I must be missing something. I too develop in feature branches, and then they're merged into develop or main (with a merge commit, obviously). Reverting that is too only a single revert. The only problem is that sooner or late those feature branch do get deleted, and if you swashed, you lose all the non-squashed history. If you don't, it's still in the develop/main branch. What do I miss?
mfontani 6y ago
You get a similar benefit (a single revert to revert it all) via "git merge --no-ff BRANCH". If the BRANCH is a fast-forward (i.e. it's been rebased to master/main & tested before merge) then you get both benefits of a clean history and an easy revert, for little downside. Keeping the history of each incremental change, even in a branch, is IMO too useful to give up. Note I'm not advocating keeping those "fixed typo in previous commit" fix-up commits: those should be properly fixed up _before_ merge, by judicious use of git rebase.

lordnacho 6y ago

The only time I ever do it is if it's trivial. Say I've removed some vestigial code, then I find some more after I've committed.

aequitas 6y ago

Depends on the Git craftmanship of the team is my experience. If they commit every small fix with a useless commit message, history becomes messy real quick. Squashing can be seen as a solution here. Until you learn proper rewriting of history as in (interactive) rebasing. After which you can put you code changes in every commit you want and order them around as you see fit. But that also depends on the Git workflow that is used and how much branches are shared amongst team members. I had one job in the past that used Gerrit[0] as Git tool. One of it's features is that it creates a "pullrequest" for every commit in the branch you push. Which needs to be reviewed individually. This is really anoying if you're used to organising your work in lot of commits to record each step of your developerment. But from a project's Git history perspective it makes a lot of sense. As every commit is 1 change, one feature, one contained unit, that is added to the main branch. So instead of the main branch now containing countless commits with each developers complete history on a specific feature (where code is added in one commit to be removed in the next) it contains the features as distict commits, making them easy to bisect and revert if needed. This looks a lot like squashing but because you do it before you push your code you learn to put much more thought into that single commit and the commit message. [0] https://www.gerritcodereview.com/ https://www.gerritcodereview.com/

saurik 6y ago

I think what you really want is neither of squashing nor retaining: what you want is to take the messy history you had and then reconstruct a history that makes sense and commit that; thankfully, git makes this easy. I hate it when people leave messy thoughts in the commit history as I do use the history, and it is even worse if they just leave mega-commits. I want to see easy to review step by step organized thoughts designed to help the reader appreciate the series of steps needed to bring you from where you were to where you went.

twic 6y ago
I would say the best thing is to cultivate the habit of thinking and working cleanly, so you create a history of small, logical, incremental commits. But the second best thing is to think and work messily, and use rebasing to fake a history of small, logical, incremental commits!

simias 6y ago

I often do intermediary commits that don't compile or break something significant, only to make sure that I don't lose the code. When that happens I always squash my commit afterwards once the code is in a usable state. The alternative is making bisecting harder which is not something that I want. I want every commit to compile and be testable individually. That definitely doesn't mean that I think it's a good idea to have "gargantuan" commits. An ideal commit should contain a single, atomic change to the codebase. Not more, but also not less.

rutthenut 6y ago
I'm a bit confused on your comments here. You state "I often do intermediary commits that don't compile ... to make sure that I don't lose the code" And follow that with "I want every commit to compile and be testable individually."
- simias 6y ago
  I mean that I do many small "crap" commits while developing, once I'm ready to merge into the main branch I clean the history to get proper, atomic commits.
- StanLindsey 6y ago
  I'm the same as OP. I commit constantly when hitting a natural stop point or when taking a break and push up to my branch/pr. I hate having code locally that hasn't been pushed to the origin. But doing this means I have many commits that don't mean anything or are unfinished and in an uncompilable state. So I git rebase and massage the history to make more sense.

clinta 6y ago

Everyone who works on Linux must rebase and squash commits so that every commit builds and passes tests, and does a single thing. More about how Linux uses git: https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html https://www.mail-archive.com/dri-devel@lists.sourceforge.net... https://www.linux.com/news/why-linuxs-biggest-ever-kernel-release-is-really-no-big-deal/ https://www.linux.com/news/why-linuxs-biggest-ever-kernel-re...

alkonaut 6y ago

You don't have to squash into ONE commit just because you squash. If I make 10 commits I can squash it into two logical commits (e.g. refactor, add feature) then I merge the branch with those two. If the branch is small and has 3 commits that are one logical change, then I might as well squash to main instead of merging. Commit history is readable regardless (I'd never use anything but --first-parent ever).

mcv 6y ago

I do read the git commit history, and specifically to find problems like these. Squashing commits indeed sounds like a terrible idea to me. There are also people who insist you always need to rebase your commits before pushing, in order to get a nice, linear history, and again I disagree. It's fine when you're rebasing a very short (single commit) history, but for a long history, it not only gets very tedious, but when it introduces new bugs halfway through that history, you may not notice. You will notice later, and then tracking that bug you end up in the middle of your own (rebased) history and you may wonder why you ever did something so stupid, when the actual cause of the bug was the merge of two histories at the end of your work. I do rebase sometimes, but only when the history is short and I can easily see what I'm rebasing. A history longer than 2 commits should not be changed. I never squash.

reallydontask 6y ago

From experience of working with new CI/CD systems where one doesn't quite understand what's failing due to ... reasons. It's really quite easy to get into the 50s or close to 100 commits in a branch, which can lead to a horrendously messy history. There are also people that like to commit before the try something locally and their branches are effectively a mess. All of the above is magnified in a monorepo environment, where you might have thousands of commits a day against master if it weren't for enforcement policies that force a squash.

timvdalen 6y ago

It depends on the situation. If I'm merging a feature branch that has a lot of commits that effectively make up one feature (because a dev had to go back and forth or because there was a lot of feedback), I might squash those commits into one before I merge it into master. As mentioned elsewhere in the comments here, that also makes it a lot easier to revert said feature if something goes wrong.

3np 6y ago

Routinely. Common example that I can't see why anyone would take issue with: * Commit 1: Fix a bug * Commit 2: Fix linting issues with the fix discovered through CI * Commit 3: Remove dead/commented code introduced thrugh commit 1 * Commit 4: Update documents as required by change I'd always squash those into a single commit before merging into upstream.

asveikau 6y ago
I can see a good case for separating #2 from everything else. Or depending on the change, maybe squashing #2 and #3 together separate from 1 and 4. It's a good idea to isolate the bugfix so that reading the diff is clear. Stylistic changes such as #2 and #3 can be separated and called out as "should produce no behavior change" sort of updates.

ratww 6y ago

Squashing is kind a blunt tool that is useful sometimes, but can be perfectly replaced either by crafting your commits with more care or doing interactive rebasing. I once had to enforce to an developer that wanted to make 20 commits per PR that were titled like "wip" "wip" "wip" "fix bug" "fix mistake" "format code" in a PR that only changed like 10 lines of code in the end. In this case, the main problem for me was that git blame became useless because this developer was touching way more lines than necessary and then undoing it using the code formatter.

rjkennedy98 6y ago

Yes, our company squashes commits (we have tens or probably hundreds of thousands on the main branch). Yes, I routinely look at commit history. Commit history is also used for doing analytics for performance reviews such as how many commits did you make, what percentage had tests ect. For instance my last performance review made note that I had test coverage on 90% of my commits. Also, we auto-stamp the PR on the commits so we can get the context. I don't understand how anyone could make sense of a large codebase when all the commits are added with the standard inane commit messages (e.g. "fix it", "typo", "name changes", "tests") that people do when building a feature. I routinely have to look at a piece of code, do a git blame, get the PR in the commit and figure out what was being done.

CGamesPlay 6y ago

I'm probably 75/25 on this. 75% of the time I'm gonna squash, because my entire commit messages is along the lines of "got to this point" or "fix frotzolate when x=7". 25% of the time my first round of squashing yields good commit messages that are isolated and complete, so it's better to leave those as separate commits when merging into the mainline. I also aggressively reorder my commits. When it gets to yak shaving you basically develop in a stack, so you end up with a half-functional commit to system A at the top, then a complete commit to system B, then the finishing commit to system A, so it's better to just rearrange it so that you have one system B commit followed by one system A commit. But I do routinely read the commit history (using git blame) and no I don't want to see the "complete story" of my past self having "got to this point"--I want the documented MR commentary.

__s 6y ago

We do. PRs are generally smaller than 3 years of development. Sometimes refactoring will be split out so what could be a single PR with multiple commits instead becomes multiple PRs. This allows review to be focused on each PR & enforces that each commit maintain CI passing

UK-Al05 6y ago

# Implement feature # Whoops fixed issue in feature i just implemented # Add in whitespace # Remove whitespace # Forgot place to add in whitespace # Fix variable name for feature Vs # Implemented feature "x" Which ones easier to rollback and read.

chousuke 6y ago

Personally I think of working in a branch as the process of creating a patch set. A patch in a series should only depend on its predecessors. You can submit more than one patch in a pull request. I would never send out a patch set for review that includes all the "oops" "typo" "iteration 50" etc. commits I make as I work on code. Those are pure noise. However, git is a tool for development, and during development I should be able to use git in whichever way is convenient for me: commit, rewrite and do whatever the hell I want with my local history. Not having that freedom is the primary reason why working with most non-distributed version control systems is such a pain. When it comes to actually merging patch series to master, I like not doing fast-forward merges, since you maintain a natural grouping of the applied changes.

DrBazza 6y ago

> Do people out there actually squash commits? Yes, squashing parts of a discrete piece of work together, where it makes sense, then makes it trivial to git bisect any future problems. Code committed to the mainline should always compile, and should be made of discrete changes. However, do what you like on your unpublished local branch. > What's even the point of it? It's not like people routinely read the commit history, and when they do, they really would like a complete story, not 20 gargantuan commits that contain 3 years of development. My company routinely reads the commit history. The commit is usually the 'why', and the code is the 'how'.

Vinnl 6y ago

Yes I do (well, I rebase, not squash blindly), but I do read the commit history. Or well, not so much the complete history, but I do go looking for which commit introduced a particular line, what message went with that change, and what else changed with it. Of course, that only works after you leave proper commits. The reason people don't do that is because you only look at your commit history if you've kept it useful, but if you've never looked at your commit history because it's not, you don't know the benefits of keeping it useful.

vonmoltke 6y ago

It really depends on where you work and how your company's repo is organized. For instance, where I work 20 squash commits would represent, at most, 10 minutes worth of commits to the monorepo. Not squashing on merge would quickly turn thousands of daily commits into tens of thousands. It's already impractical to find suspect commits via git, and we typically use our code review tool to find the change that broke something (and that change includes the developer's full branch history). Adding more commits would needlessly slow down the tooling that displays 'git blame' results (and likely other commands). I suspect there is a pattern in the comments here. People who work on small teams with granular repos that, individually, don't see a lot of daily activity think squashing is bad and erases valuable history. People who work with large repos that see high commit velocity (like a monorepo) think squashing (at least merge squashing) is beneficial and don't see the loss of information as problematic because it's hard to access it in the first place. Maybe I'm just projecting my own opinions on this; I'd like to hear perspectives that conflict with my assumptions.

spdionis 6y ago
You are definitely correct. People who argue against squashing have not worked on 10+ years old actively developed repositories, or in big enough teams. A commit is a change. A change has a ticket. A ticket is a small piece of work that does not result in 3k changed lines. This ensures that the change rationale is fully documented and easily identifiable. Nobody needs those "fixed typo" commits. Nor the "implemented function A" commits. What IS the change that you're doing? What functionality? That's the most comfortable commit granularity to debug imho.
- mixmastamyk 6y ago
  Agreed, I regularly add comments later as well. Understanding often comes after the code works. I could obsessively fiddle with every commit like an artesenal snowflake, or I could click the squash checkbox on the request.

mixmastamyk 6y ago

That's not how it works, really. A simplified workflow: You take bug or enhancement of a couple of points, work on it on its own branch, then merge req+squash the mostly noise commits into a develop/master at once. A chunk is approximately 3 days, not 3 years. For forward-looking projects, it saves time and works well. "Enterprisey" projects maintaining legacy branches are less well served.

kelnos 6y ago

It's a mix where I work. Most people aren't at all tidy with their commit history, and I'll often see a PR with a fairly small final diff (maybe a couple hundred lines changed total) with several useless one-word commit messages like "fix". And then after the PR has gone through review, most people tack on extra commits with equally-useless commit messages like "addressing feedback". It's infrequent that I see PRs with commit histories that actually chronicle the history of the change itself; it's more a chronicle of the developer's changing thought processes as they try different things, go down blind alleys, change approaches several times. Most of the individual commits have test suite failures and some of them don't even compile, so it's impossible to bisect across them if an issue is later found. In those cases, I wish people would just squash (and some do, where I work). Yes, you lose information and separation, but I'd rather have one large working commit than 15 small broken commits followed by one working commit. Ideally people would curate things before submitting their PR, but I've found that most people just don't care, or don't understand git well enough to even attempt to do it. Sometimes I toy around with the idea of trying to teach people (what I consider) better practices, and insist they are followed, but we all have a limited amount of social capital in our workplaces, and I'm not convinced this is something worth spending it on.