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

141–150 of 333 posts

Re: Fortunately, I don't squash my commits

#141

Post by savrajsingh »

alxmng wrote: post #55
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…

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.

Yes

Re: Fortunately, I don't squash my commits

#142

Post by leejo »

nailer wrote: post #93

Hijacking the top thread to make an important point: - "Squash your commits" folks - yes, it's good to be able to revert a commit and remove entire features and have a readable commit history. - "Make small granular commits" folks - yes it's good to be able to bisect and see where exactly some behaviour changed. Rather than repeat these points (which are both true), there's a better question to be asked: Should there…

You can revert a merge commit by providing which side of the merge is mainline:

    git revert -m 1 $sha_of_the_merge_commit
That provides the "revert a commit and remove entire features" use case, assuming the original feature was all encapsulated within the merge (branch) in question. You can get the "readable commit history" with:

    git log --no-merges
You can have the best of both worlds. git has had these features for as long as I can remember, but devs have had the "NO MERGES ONLY CLEAN HISTORY" platitude repeated so often they must think git lacks an alternative.

Re: Fortunately, I don't squash my commits

#143

Post by xorcist »

This article presents a very good argument clean and squashed commits are important, under a click-baity title.

The ability to use git bisect effectively is one of the more important reasons to enforce a clean and readable commit history by squashing and rebasing before merge.

A history where the majority of commits doesn't even compile ("sorry, updated test value was wrong", "oops syntax error", "forgot to update these references in the last commit", "big refactor wasn't complete") is a major headache not only to readers but to anyone using automated tools such as bisect. The author here was lucky the commit history was in a good shape. The size of the offending commit was reasonable too, so any trivial commits had been squashed away here.

My personal issue with this particular commit is the useless commit message. "Extract CreateTokenValidationParameters method". Well, obviously. But why? What was this intended to result in? Why was particular change made and not something else?

A more suitable commit message would have included something along the lines of "JwtSecurityTokenHandler methods belong conceptually with other code that configures JWT parameters. Break them out to CreateTokenValidationParameters because ..", that would have make much more sense and made the change easier to understand for someone else!

After all, this is how the author describes the patch, when taking the time to do so in order to write a blog post. It isn't that hard.

Re: Fortunately, I don't squash my commits

#144

Post by Chris2048 »

aurelianito wrote: post #3

I never understood the need to squash commits (or rebase). If you do merge requests and use merge commits (like GitHub or gitlab do). A "nice" history is a small script away. It should even be a part of the GitHub/gitlab gui. Do not loose information about the development history!

I squash most feature PRs, but this is into a dev/qa branch initially. This is later merged into the actual release branch where we obviously want to maintain each of the individual commits.

Reason for the feature squash: most of the context of the original commit(s) are meaningful only to the original dev who is free to keep that history locally (or share with others). There are time's it's convenient to structure the commits in a certain way, but this is often most useful at PR review time, and less so after merge.

Granted, you may want to be able to re0review code at a later date, and hence keep that structure, but hopefully this is a rare case, and PRs and not often so huge.

Re: Fortunately, I don't squash my commits

#145

Post by KallDrexx »

dastx wrote: post #86
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.

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

I personally really dislike merge commits because it makes the tree really difficult to follow in most visualizations. If I'm trying to follow the main branch only to a certain point the graph is polluted with all the "WIP" side branch commits between head and the commit I end up getting to.

It also defaults to causing the main to have a ton of commits with "Merged from XXXX branch" as the summary lines when that's not nearly descriptive enough to quickly find what type of commit I may be looking for.

Re: Fortunately, I don't squash my commits

#146

Post by mumblemumble »

xorcist wrote: post #143

This article presents a very good argument clean and squashed commits are important, under a click-baity title. The ability to use git bisect effectively is one of the more important reasons to enforce a clean and readable commit history by squashing and rebasing before merge. A history where the majority of commits doesn't even compile ("sorry, updated test value was wrong", "oops syntax error", "forgot to update th…

I would say that this is a good argument for linearizing the history by rebasing, but certainly not for squashing.

Git bisect can only narrow you down to the scale of your commits. If you do infrequent, large commits, it's not very useful. If you do frequent, small commits, it's great. If you do frequent, small commits and then squash them into infrequent, large commits, it's not very useful.

There are plenty of reasons to squash (and, personally, I generally think they outweigh the arguments against), but this is not one of them.

Re: Fortunately, I don't squash my commits

#147

Post by mfontani »

swalsh wrote: post #40
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 do, all the time. I highly recommend others do it too. I like to keep to 1 commit per ticket (even a super large ticket that might take me weeks of development). But having a commit history like the fella in this story is nice too. So what you should do is work in a feature branch. On the day of deployment I'll squash, and cherry pick (in my case to a train). If the deployment goes bad, and my code is at fault, the…

You get a similar benefit (a single revert to revert it all) via "git merge --no-ff BRANCH". If the BRANCH is a fast-forward (i.e. it's been rebased to master/main & tested before merge) then you get both benefits of a clean history and an easy revert, for little downside.

Keeping the history of each incremental change, even in a branch, is IMO too useful to give up.

Note I'm not advocating keeping those "fixed typo in previous commit" fix-up commits: those should be properly fixed up _before_ merge, by judicious use of git rebase.

Re: Fortunately, I don't squash my commits

#148

Post by matheusmoreira »

Aeolun wrote: post #123
matheusmoreira wrote: post #109

Earlier quoted context omitted.

A merge commit works just like a squashed commit except it keeps all history. This is precisely why it's sensible to avoid fast-forwarding since that operation discards the fact that a branch existed in the first place. It's better to always have merge commits. They can be reverted just as easily. I don't understand why merge commits aren't the default in git.

If you can fast forward the fact that the branch ever existed was irrelevant, since the branch is a direct child of what you based it on. Just with a different name.

It's not irrelevant. The branch represents a feature, a topic. It groups the commits you're merging into one logical set. This grouping of commits is exactly what will let you revert the feature later if it causes problems.

Re: Fortunately, I don't squash my commits

#149

Post by tasogare »

twic wrote: post #48
np_tedious wrote: post #27

Earlier quoted context omitted.

The argument for squashing is that minor updates like spelling, renaming, or test fixes during initial development can really clutter the history if they each have a commit. Many would rather see the actual change "Update X to use Y instead of Z" in the history, and minor details like "Fix mock in XTestCase" or "Perform renames from code review" within that single commit. I'm sort of agnostic on this issue, but I do…

For me, it's the other way round: minor updates like spelling, renaming, or test fixes during initial development can really clutter the major updates. If i am making a commit that makes a complex but important change to some significant application logic, i want that commit to contain that change and only that change , so that when i have to re-read it a year later, it's completely obvious what i did and why. Bundli…

Interesting idea, however this could also be easily abused for nefarious use.

Re: Fortunately, I don't squash my commits

#150

Post by jerf »

_-___________-_ wrote: post #112

The most striking thing in this story for me has nothing to do with commit squashing. Faced with something that suddenly stopped working, the developer went on a wild goose chase, first decoding their JWT -- presumably the same one that "used to work" -- then looking for possible framework bugs or misconfiguration, before looking at their own code, the single most likely place that the bug would be. They even linked…

"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 an unusual enough experience to write a blog post about.

Post reply on HN