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

111–120 of 333 posts

Re: Fortunately, I don't squash my commits

#111

Post by Aeolun »

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…

Why would you want one author for a merge commit? That merge can have many commits by many different authors.

Re: Fortunately, I don't squash my commits

#112

Post by _-___________-_ »

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 to select is rarely broken but failed to internalise the main lesson behind it.

Whether they squashed their commits or not would make a far smaller difference to the time taken to spot the bug than simply not assuming that it's everywhere else than their own code first.

Re: Fortunately, I don't squash my commits

#113

Post by scoutt »

Side comment: it's curious how the author went from "not my code", to "the problem was in the code".

I say this because as a low level/system developer, I often have to solve problems for the people integrating my platforms from higher level languages. When something doesn't work they come to me, and it often goes like this (with quotes from the article):

First stage: someone else's fault.

"the problem is environmental: a network topology issue, a bad or missing connection string"

Second stage: magical things, but not my code.

"Not my code ... the problem occurs somewhere in the framework"

Third stage: acceptance.

"Global variables are evil. Who knew? ... It took me hours to find the bug, and ten seconds to fix it."

Re: Fortunately, I don't squash my commits

#114

Post by Joker_vD »

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…

Wait, I must be missing something. I too develop in feature branches, and then they're merged into develop or main (with a merge commit, obviously). Reverting that is too only a single revert. The only problem is that sooner or late those feature branch do get deleted, and if you swashed, you lose all the non-squashed history. If you don't, it's still in the develop/main branch.

What do I miss?

Re: Fortunately, I don't squash my commits

#115

Post by rjkennedy98 »

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.

Yes, our company squashes commits (we have tens or probably hundreds of thousands on the main branch). Yes, I routinely look at commit history. Commit history is also used for doing analytics for performance reviews such as how many commits did you make, what percentage had tests ect. For instance my last performance review made note that I had test coverage on 90% of my commits.

Also, we auto-stamp the PR on the commits so we can get the context. I don't understand how anyone could make sense of a large codebase when all the commits are added with the standard inane commit messages (e.g. "fix it", "typo", "name changes", "tests") that people do when building a feature. I routinely have to look at a piece of code, do a git blame, get the PR in the commit and figure out what was being done.

Re: Fortunately, I don't squash my commits

#116

Post by Aeolun »

teekert wrote: post #102
m12k wrote: post #77

Earlier quoted context omitted.

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

Like a tag? (I'm a git beginner so no sarcasm here, really I'm really interested in this stuff.)

The problem is if multiple people make other changes after yours. You can certainly go back to your tag, but you lose all their changes as well.

If you revert one specific commit it just does another commit with the exact inverse of what happened in the reverted commit, so all other changes are preserved.

Re: Fortunately, I don't squash my commits

#117

Post by falcolas »

Mazzen wrote: post #59
twic wrote: post #54

Earlier quoted context omitted.

> If I had spread that endpoint across 25 commits, I'd have to actually debug the issue in QA and figure out what I broke No, you could just revert the entire lot in one go.

that's not a valid argument. How do you identify "the lot"?

    last_prod_tag

Re: Fortunately, I don't squash my commits

#118

Post by twic »

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…

I'm intrigued to see that there are (by my count) three of us making this point today. Perhaps this is an idea whose time is finally coming.

Re: Fortunately, I don't squash my commits

#119

Post by CGamesPlay »

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'm probably 75/25 on this. 75% of the time I'm gonna squash, because my entire commit messages is along the lines of "got to this point" or "fix frotzolate when x=7". 25% of the time my first round of squashing yields good commit messages that are isolated and complete, so it's better to leave those as separate commits when merging into the mainline.

I also aggressively reorder my commits. When it gets to yak shaving you basically develop in a stack, so you end up with a half-functional commit to system A at the top, then a complete commit to system B, then the finishing commit to system A, so it's better to just rearrange it so that you have one system B commit followed by one system A commit.

But I do routinely read the commit history (using git blame) and no I don't want to see the "complete story" of my past self having "got to this point"--I want the documented MR commentary.

Re: Fortunately, I don't squash my commits

#120

Post by __s »

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.

We do. PRs are generally smaller than 3 years of development. Sometimes refactoring will be split out so what could be a single PR with multiple commits instead becomes multiple PRs. This allows review to be focused on each PR & enforces that each commit maintain CI passing
Post reply on HN