Hacker News Reader

Comment by aurelianito | Hacker News Reader

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.

View on HN

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.

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.

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.

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?

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.

That's not what would happen though, by default the resulting commit message contains the messages from all those squashed into it.

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".

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!

Reply on news.ycombinator.com