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

71–80 of 333 posts

Re: Fortunately, I don't squash my commits

#71

Post by bJGVygG7MQVF8c »

adrianN wrote: post #49
jdmoreira wrote: post #35

Earlier quoted context omitted.

I religiously squash my commits for each merged pull request. I seems like madness any other way to me... why have a bigger granularity than a single merge commit?

Granularity helps with bisecting issues.

Yes. But also: Granularity undermines the effectiveness of bisecting when your commits aren't ACID.

These conversations are so often tedious and repetitive largely because engineers seem incapable or unwilling to apply systems thinking to development practices.

Re: Fortunately, I don't squash my commits

#72

Post by magicalhippo »

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

By the ticket/issue number?

Re: Fortunately, I don't squash my commits

#73

Post by grumple »

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…

You very rarely want to rollback a major feature. I’ve never seen it done except right after a deployment, in which case you can revert the merge commit instead. Bisect to find a breaking change is a very common operation. Squashing is bad if you expect to work on your project long term or if others may have the same commits as you from working on the same feature branch.

Re: Fortunately, I don't squash my commits

#74

Post by golergka »

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…

The fix is very easy: forbid fast-forward merges, and then you can always revert the merge commit of particular feature branch.

As for cleanliness of history, everything should be as simple as possible, but not simpler. Squashing and rebasing is destroying history, which often could be valuable, as OP shows.

Re: Fortunately, I don't squash my commits

#75

Post by alkonaut »

pbalau wrote: post #52
Kihashi wrote: post #12

Earlier quoted context omitted.

I find the individual commits on feature branches to be more noise than signal after they are merged . They can be useful during review, sometimes, but mostly I want a cleaner history. > they really would like a complete story, not 20 gargantuan commits that contain 3 years of development That sounds like maybe we split up work differently. 3 years of development for me or my team would likely have hundreds+ of merge…

If you look at the PRs list, you will have a clean and tidy history.

Yep, but many tools (most notoriously git bisect, famous from the article) doesn't understand "--first-parent" which is ridiculous. The only way to have a clean history that all tools accept is clean, is basically to outlaw merges.

Re: Fortunately, I don't squash my commits

#77

Post by m12k »

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 one go

Re: Fortunately, I don't squash my commits

#79

Post by alkonaut »

barrkel wrote: post #64
FeepingCreature wrote: post #14

Earlier quoted context omitted.

I squash commits. Well, I rebase so that changes are logical rather than historical. This is because when people read the commit history, which actually happens regularly, they would actually like a complete story, not 15 commits of "fix audit", "fix review" and "fix typo" - let alone refactors where previous work in the PR is thrown out, which you can by definition never care about. Commits so small that they're non…

Bisect doesn't have a problem with intermediate broken states, actually. It's why git bisect skip exists. It may not be able to pinpoint an exact commit though.

Bisect does turn into my colleagues feature branch with 20 broken commits and unrelated content though, when I just want to bisect the main branch. That's infuriating and imho makes bisect almost useless. That there is no git bisect --first-parent is one of the greates mysteries of git.

Re: Fortunately, I don't squash my commits

#80

Post by barrkel »

Squashing gets you in the habit of force pushing, and force pushing greatly increases the risk of clobbering someone's work. I've seen a lot more hours wasted on lost commits than I find credible to be wasted in slightly more verbose history.

Squashing also turns cherry picked commits into merge conflicts.

I'm not a fan. I can always go back to the feature PR and read the ticket details and diff commentary when I want the history with a full diff. And of course very old history isn't very relevant because less of it remains in the present, so rot of ancillary systems isn't a huge concern.

Post reply on HN