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

271–280 of 333 posts

Re: Fortunately, I don't squash my commits

#271

Post by Nursie »

FeepingCreature wrote: post #14
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.

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 non…

When I read the commit history I want to see what was committed.

"Hmm, I had a half working X509 chain resolver there that turned out to be unnecessary at the time but would save me a day's work now..."

Re: Fortunately, I don't squash my commits

#272

Post by Vinnl »

pierrebai wrote: post #222
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…

If you work on a very large projects with many released version and need to cherry-pick fixes to back-port, you'd be very, very, VERY glad that each branch got squashed. The story told in the article mainly shows to keep your PR focused. You can squash as long as you don't do 2-week-long 37-commits branches.

When rebasing my branches, most PRs will still be a single commit, some will be two or three. That's not that much worse than squashing, and far more informative.

Re: Fortunately, I don't squash my commits

#273

Post by Vinnl »

sixstringtheory wrote: post #230
takeda wrote: post #214

Earlier quoted context omitted.

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)

If you haven’t yet, check out rebase’s --autosquash option, along with git commit --fixup or the commit message directives “fixup!” and “squash!”

I just learned about that recently, but haven't been able to put it in practice yet. The problem I encounter is having to specify which commit to fixup to when calling `--fixup`, which I think means having to look at my commit history. Instead, my process so far includes just describing the commit I want to fixup in my commit message, in a way that makes sense to me when I'm going through the interactive rebase.

Do you have a good way to deal with this?

Re: Fortunately, I don't squash my commits

#274

Post by Vinnl »

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)

Yes, that's exactly my process. In fact, I'm not even sure if I could predict what would happen when calling rebase without `-i`. Basically, my shell just autocompletes "git reb" to "git rebase -i origin/master".

Re: Fortunately, I don't squash my commits

#275

Post by Vinnl »

im3w1l wrote: post #235
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…

It's not fun if you rebase, and realize that every single one of your many commits need to hand-merged.

But you need to deal with those conflicts before merging anyway? And they're a lot easier to deal with in the context of the individual commits than when dealing with one big merge commit, I find.

Re: Fortunately, I don't squash my commits

#276

Post by seba_dos1 »

corytheboyd wrote: post #219
takeda wrote: post #214

Earlier quoted context omitted.

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!

I believe that if you don't know interactive rebase, you don't know git ;)

Especially "git rebase -i -r" is an incredible tool.

Re: Fortunately, I don't squash my commits

#277

Post by Vinnl »

wcarss wrote: post #228
corytheboyd wrote: post #217

Earlier quoted context omitted.

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.

It's interesting that you note it only takes one person to undo the progress -- by the reverse token, every person who works in this way adds value to the practice and the history, which is why (and how) I've advocated for and to individuals to spend time on it. Any one person can muddy the history up (by ruining bisect, say), but any one person can also improve it (by leaving good notes and right-sized commits whene…

I notice that I get sloppy when I'm working on a repo with others that are sloppy as well. I guess the reason is that, if looking at the Git history is not useful half the time (because you end up at uninformative commits by other contributors), then you stop looking at the history, and then there's not much reason to leave it in a super-clean state anymore...

Re: Fortunately, I don't squash my commits

#278

Post by hawkice »

plextoria wrote: post #137

`squash` is a tool and it's neither good nor bad; it needs to be applied where it makes sense. The title is indeed click-baity. It would have been more interesting to read that the bug/mistake was caused as a result of squashing. It's not the case and I take issue with the way the author describes his commits. The problematic commit is described "Extract CreateTokenValidationParameters method", without an explanation…

I think you're missing out on the main advantage the article points out: lots of small commits, even with terrible error messages, let you use tools like git bisect to find bugs. Squashed commits mean you're looking through more code, and above some small size, it won't be obvious what the issue is.

Re: Fortunately, I don't squash my commits

#279

Post by spdionis »

nikisweeting wrote: post #226
byte1918 wrote: post #105

Earlier quoted context omitted.

A clean history with proper commit names can work as a change log for you app. We actually did that and it worked quite well. In Azure DevOps the release pipelines have access to the list of commits since the previous release so one only has to simply take the titles of those commits to build it.

You can achieve that with PR titles instead of commit titles.

But then... PR titles don't show up in the git log.

Re: Fortunately, I don't squash my commits

#280

Post by spdionis »

vonmoltke wrote: post #229
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.

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 som…

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.

Post reply on HN