Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fortunately, I don't squash my commits

blog.ploeh.dk

Post reply on HN
Print view View original

211–220 of 333 posts

Re: Fortunately, I don't squash my commits

#211

Post by saagarjha »

grumple wrote: post #133
devocracy wrote: post #107

Earlier quoted context omitted.

That's not a squash or not problem, that's a your tickets are too large problem. If you normally end up with 3000 line feature commits, you're trying to do too much with individual feature changes.

Are we pretending that we, as devs, have much say in this? If our management says they want a features that’s going to take 3000 lines of code, you don’t have a choice. It’s nice if you’re somewhere where you can roll out feature mvps, but in some environments you don’t get that luxury. And some features are just monsters, either through the nature of the feature or architectural choices that were made before it was…

Then you split the feature up? It’s generally possible to do this.

Re: Fortunately, I don't squash my commits

#212

Post by Vinnl »

Joker_vD wrote: post #2

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.

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.

Re: Fortunately, I don't squash my commits

#213

Post by falcolas »

blandflakes wrote: post #190
falcolas wrote: post #117

Earlier quoted context omitted.

last_prod_tag

And if the merge of their commits interleaves with other commits from... teammates?

Thanks to the complexity of how components integrate, even seemingly disjointed components, their commits are going to matter when it comes to troubleshooting an issue.

This gets a bit more murkey with mono-repos, but even microservices can combine to create complex production issues.

Re: Fortunately, I don't squash my commits

#214

Post by takeda »

Vinnl wrote: post #204

I usually understand "squash" to mean "bundle everything in a PR into a single commit". Which can indeed break bisect workflows. There's a middle ground though: rebase your commits, but not necessarily into a single one. Before I submit a PR, I rebase my branch (which has lots of small commits, some of which undo previous work or are a work-in-progress), and make sure that every commit is as small as it can be withou…

Same here, I especially love `git rebase -i ` it opens an editor and I have an option to edit specific commits, reword the commit, squash multiple commits together (don't use this one often) or do fixup (which basically merges commit to the previous one)

Re: Fortunately, I don't squash my commits

#215

Post by wcarss »

Vinnl wrote: post #204

I usually understand "squash" to mean "bundle everything in a PR into a single commit". Which can indeed break bisect workflows. There's a middle ground though: rebase your commits, but not necessarily into a single one. Before I submit a PR, I rebase my branch (which has lots of small commits, some of which undo previous work or are a work-in-progress), and make sure that every commit is as small as it can be withou…

I admit that it takes a small bit of skill and experience to get to a place with a version control system where doing what you suggest is easy and does not consume meaningful time, but I very strongly feel that it is worth the investment.

Re: Fortunately, I don't squash my commits

#216

Post by saagarjha »

maccard wrote: post #37
ZephyrBlu wrote: post #18

Earlier quoted context omitted.

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.

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 ), and more is more in that case, even if the history isn't perfect.

That just sounds like a bad squash.

Re: Fortunately, I don't squash my commits

#217

Post by corytheboyd »

Vinnl wrote: post #204

I usually understand "squash" to mean "bundle everything in a PR into a single commit". Which can indeed break bisect workflows. There's a middle ground though: rebase your commits, but not necessarily into a single one. Before I submit a PR, I rebase my branch (which has lots of small commits, some of which undo previous work or are a work-in-progress), and make sure that every commit is as small as it can be withou…

I wish more people would naturally come to this conclusion in their careers, but many people I have worked with just don’t care about maturing their git disciplines. All it takes is one teammate who thinks it’s a waste of time to undo the progress of everyone else.

For context, my career has been in web development start ups, which generally reward the cavalier and tolerate the careful.

Re: Fortunately, I don't squash my commits

#218

Post by room500 »

jasonkester wrote: post #200
jefftk wrote: post #192

> Had this happened in a code base with a 'nice history' (as the squash proponents like to present it), that small commit would have been bundled with various other commits. This is a misunderstanding of what proponents of commit squashing advocate. Often, when working, you end up with multiple commits which represent a single change: remove debug logging and fix bug more logging debugging typo Squashing these commit…

I can only sit in amazement as I read this thread, watching seemingly smart people advocating throwing away history for the sake of tidiness. It's maddening. Those are four commits. That's what happened. It does not matter that it's untidy. It's your history. Just leave it. It will save you a lot of work some day when you need to find the error you introduced when you accidentally removed one too many lines on that "…

> It does not matter that it's untidy. It's your history.

That is only true if you are working in a personal git repo

If you are committing against a repo with many others though, having a tidy git history is important. If I discover a bug and bisect to the "remove debug logging" commit, it is hard to revert that - or to even understand what it means. I then have to go in and try to determine which feature that debug logging is for and how many commits I need to revert to get back to a sane place.

My general rule of thumb is that I squash commits (when merging to a public repo) if the commit doesn't warrant time into creating a proper commit message (explaining what I am fixing, why, etc). I have no problem creating a set of 10 commits to merge in one feature, but each commit needs to be individually reviewable and understandable.

Re: Fortunately, I don't squash my commits

#219

Post by corytheboyd »

takeda wrote: post #214
Vinnl wrote: post #204

I usually understand "squash" to mean "bundle everything in a PR into a single commit". Which can indeed break bisect workflows. There's a middle ground though: rebase your commits, but not necessarily into a single one. Before I submit a PR, I rebase my branch (which has lots of small commits, some of which undo previous work or are a work-in-progress), and make sure that every commit is as small as it can be withou…

Same here, I especially love `git rebase -i ` it opens an editor and I have an option to edit specific commits, reword the commit, squash multiple commits together (don't use this one often) or do fixup (which basically merges commit to the previous one)

Interactive rebase is the only way I do this now too, it’s so intuitive!

Re: Fortunately, I don't squash my commits

#220

Post by saagarjha »

maccard wrote: post #41
eptcyka wrote: post #8

Earlier quoted context omitted.

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.
Post reply on HN