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

251–260 of 333 posts

Re: Fortunately, I don't squash my commits

#251

Post by yxhuvud »

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…

> Squashing unrelated commits, however, doesn't help anyone.

This however is something I've seen people do. Worst case I've encountered was a group of people that squashed all commits belonging to a whole product release - we are talking a team of 6 people working full time for half a year. Absolutely atrocious behavior, but there are lots of weird people out there.

Re: Fortunately, I don't squash my commits

#252

Post by yxhuvud »

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

Here is the thing: With git, the history looks the way I want it to look like. It is not a list of how I worked and in what sequence. Unless I want it to. I generally don't and instead prefer the history to be comprehensible by someone looking for how features are put together and interact and changed over time. THAT, saves time when I need to look at it again.

Re: Fortunately, I don't squash my commits

#253

Post by WorldMaker »

bradstewart wrote: post #248
WorldMaker wrote: post #232

Earlier quoted context omitted.

> I desperately wish git had a "group commits" feature that let me manage a cluster of related commits as a single commit for the purposes of history-viewing, reverting, and cherry-picking. Merge commits work fine for most of that, you just have to adapt to merge UX/commands: --first-parent (to git log, git annotate, etc) gives you clean history viewing of just your "groups" (your merge commits). --first-parent even…

This. I hated working with merge commits until I discovered --first-parent. I'm not sure how it evaded my attention for so long.

I think it is an interesting tools problem: making interesting graph diagrams of the full git log graph is a fun and interesting problem and often looks great in screenshots, but rarely is a particularly "useful" view to most users. It's not as "fun", doesn't produce as many shiny/colorful screenshots, to build --first-parent views by default and introduce (and test) graph drill-down based user experiences.

Re: Fortunately, I don't squash my commits

#254

Post by MayeulC »

SassyGrapefruit wrote: post #239

>I've always disliked Git's squash feature, and here's one of the many reasons to dislike it. 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 question always boils down to this metric. Which happen more often... 1. A circumstance arises where the dynamics of fine grained commits make the pr…

For the best of both worlds, I like the "git alligator" workflow: always perform a merge commit when adding a feature, then use `git log --first-parent` to browse the history without seeing the intermediate commits.

https://euroquis.nl/blabla/2019/08/09/git-alligator.html first parent log isn't mentioned, though.

Re: Fortunately, I don't squash my commits

#255

Post by SassyGrapefruit »

jkubicek wrote: post #246
SassyGrapefruit wrote: post #239

>I've always disliked Git's squash feature, and here's one of the many reasons to dislike it. 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 question always boils down to this metric. Which happen more often... 1. A circumstance arises where the dynamics of fine grained commits make the pr…

Having fine-grained commits and having a clean git history aren't mutually exclusive. If you create and submit small PRs and git-squash those PRs into the main branch, you'll get the best of both worlds. FWIW, the way I use git results in me committing a lot . I treat it as, essentially a save point that I can undo to if I need to. The history for my personal branches is a mess of broken tests and false-starts on cod…

>If you create and submit small PRs and git-squash those PRs into the main branch, you'll get the best of both worlds.

I definitely advocate for this. But I've worked some at some spots with "never squashers" that deliver every PR as 119 commits and tell me this yarn about "the time having all those commits totally saved their bacon". I've just never regretted squashing my commits into something manageable.

Re: Fortunately, I don't squash my commits

#256

Post by plextoria »

couchand wrote: post #236
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…

> fixing the more glaring issue with global variables Given that this issue is within ASP.NET that's not likely to happen in one commit of this author's project.

Unless there's a way to achieve the same thing without global variables. In any case, the decision to use them can be documented in a comment or a commit message.

^: https://docs.microsoft.com/en-us/dotnet/api/system.identitym...

Re: Fortunately, I don't squash my commits

#257

Post by stormbrew »

MaxBarraclough wrote: post #241
pierrebai wrote: post #222

Earlier quoted context omitted.

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.

Perhaps we could 'have it all' if git introduced a way of bundling commits, a bit like code-folding in an IDE. The bundles could be expanded when you need fine-grain detail of development history, but by default would be unexpanded and would behave like a single big commit, avoiding the issue of always seeing overwhelming detail.

git has that, it's called a merge commit. You can use `git log --first-parent` to see them unexpanded and then find what you want to expand.

A lot of higher level tools don't expose this functionality but it's not like it's not there.

Re: Fortunately, I don't squash my commits

#259

Post by hinkley »

SassyGrapefruit wrote: post #239

>I've always disliked Git's squash feature, and here's one of the many reasons to dislike it. 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 question always boils down to this metric. Which happen more often... 1. A circumstance arises where the dynamics of fine grained commits make the pr…

Maintaining safety equipment takes time and effort we could be using for something else. But we do it anyway because when we do need it, it trumps all other concerns.

It’s better for people to get comfortable dealing with commit history than kicking the can down the road by getting the abridged edition. You’re infantilizing your coworkers, and hamstringing the people who do deep root cause analysis at the same time.

Re: Fortunately, I don't squash my commits

#260

Post by hinkley »

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…

My commit history doesn’t always reflect my mental processes in a way I expect others to follow. Particularly when I’m rationalizing committing work in progress before leaving for lunch or before writing experimental code. So rebasing to consolidate a couple commits and reorder some others is helpful.

The commit history is performance art. You don’t need to know that I left out a comma. Or that I tried to make a bit of code easier to read but introduced regressions in the process (that also breaks bisect). You do need to know that I changed this code over here because I changed the code over there and broke something, because I either missed something or you’ll have the same issue the next time.

Post reply on HN