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

231–240 of 333 posts

Re: Fortunately, I don't squash my commits

#231

Post by xorcist »

twic wrote: post #206
xorcist wrote: post #170

Earlier quoted context omitted.

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…

The difference between fixups and squashing is only in how the commit message is generated.

Both are (interactive) rebase operations. Both are established terms in git, and it is probably not very useful to change that nomenclature now.

Re: Fortunately, I don't squash my commits

#232

Post by WorldMaker »

Pxtl wrote: post #110
alxmng wrote: post #55

Earlier quoted context omitted.

Programmers can have the best of both worlds. Use granular commits on a local branch and squash merge into shared branches. That way one gets clean shared history while preserving local work history.

The problem with this approach is the local branch is no longer represented in the shared branch. So if I'm working on a larger feature and want to PR an intermediate part and continue working, I'm in for a bad merge. If I want to merge my hotfix topic branch into both the release and the master branch, their commits won't match so I can't check if it's present in both automatically. If a topic branch is left up inst…

> 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 works for bisect allowing you start by figuring out which merge commit brought in a change (and then dig into the merge branch itself if needed as a second bisect).

You can revert or cherry pick merges if you provide the -m (mainline) flag to tell it which parent to consider the mainline (usually the first parent, but not always depending on your intended revert/cherry-pick; it complicates what you need to know about the revert/cherry-pick, but if you are in the process of revert/cherry-picking you should already be figuring out what your mainline is and expecting some possible complications).

I think sometimes the only "problem" with Merge commits is too few pretty UX tools default to a --first-parent view of the git graph and don't themselves provide good tool for picking that -m (mainline) for revert/cherry-pick.

Re: Fortunately, I don't squash my commits

#233

Post by blandflakes »

falcolas wrote: post #213
blandflakes wrote: post #190

Earlier quoted context omitted.

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.

This sort of sidesteps the issue, IMO, of how hard it is to isolate a problem. Yeah sometimes things collide, but pretty often in my experience there has been one change that needs reverting or patching, not six changes that interleaved. Or rather, interleaving them at best increases the difficulty of the blame game.

Re: Fortunately, I don't squash my commits

#234

Post by couchand »

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.

Maybe... sure that's fewer commits to cherry pick. But when some reconciliation is needed to make a patch apply to different version branches, it's sure a whole lot easier to manage if the commits are small.

Re: Fortunately, I don't squash my commits

#235

Post by im3w1l »

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.

Re: Fortunately, I don't squash my commits

#236

Post by couchand »

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.

Re: Fortunately, I don't squash my commits

#237

Post by WorldMaker »

CrunchyTaco wrote: post #106
dastx wrote: post #86

Earlier quoted context omitted.

> squash merge into shared branches Why not just rely on a merge commit instead?

My gripe with merge commits is they don't integrate nicely with `git blame`. If I'm looking through historic commits (to understand why a change was made, or perhaps to debug an issue) I'll often `git blame` the line and diff that commit. If the commit is super granular, I can't get the context of the whole change: I need to dig for the merge commit then look at that, which is faff. If there's a way that I don't know…

`git blame --first-parent` will stick to merge commits in blame output.

Re: Fortunately, I don't squash my commits

#238

Post by nneonneo »

Is there a way to make git keep the unsquashed history, linking it to the squash commit? That would solve the problem here, because anytime bisection locates a squash commit you could just follow the pointer to the unsquashed history and repeat.

Re: Fortunately, I don't squash my commits

#239

Post by SassyGrapefruit »

>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 problem more obvious.

2. I have to interact with the git history

Now(and this is just me) I interact with the git history for one reason or another multiple times a day every day. I have been using git for 10+ years and I haven't yet encountered the first circumstance yet. Its not to say I won't encounter that circumstance and when I do I'll probably pine for the fine grained commits that would make it stand out.

For me the clean, easily browsable history benefits me every day. Furthermore because of how often I have to use it I should optimize it heavily at the expense of just about anything else unless the benefits of that item can be realized with similar frequency. The access to fine-grained commits hasn't helped me once in the 10 years I've been using git. With that calculus in mind I must conclude that I should squash the commits and pay the piper on the other thing when/if that bill comes due.

EDIT: Imagine this. If clean browsable history saves me 5 minutes a day then it has saved me ~10,000 minutes since I started using git. That equates to 1 full time working month. I really can't think of a circumstance where having access to fine grained commits would deliver a similar net savings.

Re: Fortunately, I don't squash my commits

#240

Post by DarkWiiPlayer »

saagarjha wrote: post #208
DarkWiiPlayer wrote: post #168

Earlier quoted context omitted.

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 ;)

I mostly deal with Lua, so no
Post reply on HN