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

201–210 of 333 posts

Re: Fortunately, I don't squash my commits

#201

Post by saagarjha »

m12k wrote: post #77
davewritescode wrote: post #45

The reason to squash commits is more than just keeping your commit history read-able, it's about making easy to revert a feature and being able to keep history in a way that makes it simple to revert a change if you run into issues. If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I'm a simple git revert away from fixing the issue. If I had spread that endpoint across 25 commits…

> If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I'm a simple git revert away from fixing the issue I'm firmly of the belief that any benefits that squashing brings would be better achieved with better tooling, rather than by re-writing history and throwing away potential debugging information. In this case, what you need is for git to make it easier to revert 25 commits in on…

How about the case where I made a commit because I wanted to switch to my laptop and continue working? Why should I keep that around ok my history?

Re: Fortunately, I don't squash my commits

#202

Post by DrBazza »

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.

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

Re: Fortunately, I don't squash my commits

#203

Post by kelchm »

Great discussion in this post. While I do generally prefer squashed commits when merging a branch, I absolutely seen that cause some pain in specific circumstances.

I think part of the problem is that modern repository software has built an 'additional layer' on top of git (IE: pull requests) that most of us have become accustomed to using in our day to day workflows. Git itself doesn't really have a 'lossless' way to persist that extra information.

Squashing commits at merge gets us close, but ultimately we’re throwing away potentially useful information by doing so. The main time I’ve seen it be problematic is when multiple people are working on a complex feature where PRs are getting merged into a long-lived feature branch rather than directly to the default branch.

Say I need to base my work on someone else’s WIP branch for said feature. If they squash their commits when merging their work into the feature branch, I’m going to end up with merge conflicts that need to be manually resolved as the individual commits that I had based my work on no longer exist, as they’ve all been squashed into a single new commit.

What if git supported a sort of 'soft squash' concept, where associated commits could (optionally) be grouped together with additional metadata. That would let the application consuming the git history (IDEs, CLI tools, etc) make the decision in how commit histories are presented to the user.

Re: Fortunately, I don't squash my commits

#204

Post by Vinnl »

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 without including work that is halfway done (so all tests still succeed), and have a clear description of what they're doing.

I then have both a nice history, and I can bisect to find a problematic commit, or inspect the commit history of a single line to get more context about it.

Re: Fortunately, I don't squash my commits

#205

Post by saagarjha »

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

There’s “throwing away history” and then there is just clutter. If you added a feature and then ten commits to fix typos on top of it, just squash it into the original one and pretend like it was right all along. It keeps the repository sane and not full of “typo fix” commits, and, like, I don’t really mind looking for a change in a diff that is 20 lines instead of a dozen that are one.

Re: Fortunately, I don't squash my commits

#206

Post by twic »

xorcist wrote: post #170
twic wrote: post #57

Earlier quoted context omitted.

Nobody is suggesting you should make commits so small they're non-functional.

Are you simply suggesting the removal of those non-functional commits to be called something else than "squashing"?

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

Re: Fortunately, I don't squash my commits

#207

Post by kordlessagain »

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 will save you a lot of work some day

I already spend a fair amount of time on other people's problems and they aren't doing much to save me, so what is the point of being obsessive with my own problems such that I may avoid spending a little bit of time on them later?

Re: Fortunately, I don't squash my commits

#208

Post by saagarjha »

DarkWiiPlayer wrote: post #168
jerf wrote: post #150

Earlier quoted context omitted.

"went on a wild goose chase" Because 19 times out of 20, that "wild goose chase" finds the bug faster. As there is no perfect debugging methodology, sometimes whatever method you use will go wrong and you'll end up on the bottom of your list of things to check, or worse, right off the bottom of the list. (Those are some bad days.) That is not, itself, proof that your list is broken. After all, the author found this a…

Over the years I've figured out that you can not only bisect in your development history, but also in the program runtime. Start with "print('1/2')" or whatever around halfway through the runtime of your code and see if you get there, then move to 1/4 or 3/4, etc. This can be done with break points, of course, but in my setup adding a print is usually just faster.

I suspect your projects don’t take a while to build ;)

Re: Fortunately, I don't squash my commits

#209

Post by mpawelski »

ZephyrBlu wrote: post #7

If you use Pull Requests with squashed commits, you can do exactly the same process as described here by isolating the issue to a PR then restoring the branch and bisecting from there. It seems like a small price to pay for a clean history, given the rarity of occurrences like this.

You mean Gihub? I'm not familiar with squashed commit there but it seems that it requires that original branch is not removed from remote? Because if there is no reference to this branch then it will be garbage collected after some time.

You don't remove PR's branches after merging them?

Re: Fortunately, I don't squash my commits

#210

Post by Vinnl »

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's not my history. My history includes every time I hit Ctrl+Z without doing a commit in between.

But you wouldn't commit every keystroke, because it's not informative. It doesn't tell you anything about why you did something.

We're not advocating throwing away history specifically, we're advocating writing helpful history, leaving helpful traces.

Post reply on HN