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

261–270 of 333 posts

Re: Fortunately, I don't squash my commits

#261

Post by fishywang »

SassyGrapefruit wrote: post #255
jkubicek wrote: post #246

Earlier quoted context omitted.

Having fine-grained commits and having a clean git history aren't mutually exclusive. If you create and submit small PRs and git-squash those PRs into the main branch, you'll get the best of both worlds. FWIW, the way I use git results in me committing a lot . I treat it as, essentially a save point that I can undo to if I need to. The history for my personal branches is a mess of broken tests and false-starts on cod…

>If you create and submit small PRs and git-squash those PRs into the main branch, you'll get the best of both worlds. I definitely advocate for this. But I've worked some at some spots with "never squashers" that deliver every PR as 119 commits and tell me this yarn about "the time having all those commits totally saved their bacon". I've just never regretted squashing my commits into something manageable.

The problem is not on squash. The problem is on "PR" itself.

The pull request workflow popularized by Github and adopted by others (like Gitlab) is just bad for code reviews. They force you to choose between squash and history. Making several, smaller PRs are not the universal solution either. In a lot of cases those PRs have a dependency over each other and dependent PRs is also a pain in the ass in Github's PR workflow.

In a better code review system you don't have to make that choice. For example, in Gerrit (I _think_ this is also similar in phabricator, but I'm less familiar with that), every code review will end up a single commit when it's merged (if you configured it so, and that's the default configuration), and you don't lose the history during the workflow, all the intermediate states are stored as git refs on the server (you can't use bisect on them though, but they are there and you could write your own custom script similar to bisect to loop through them). Code reviews with dependencies are also handled naturally.

Re: Fortunately, I don't squash my commits

#262

Post by maccard »

saagarjha wrote: post #216
maccard wrote: post #37

Earlier quoted context omitted.

We go through ~600 commits per day. In my experience, there's nothing worse than looking for when a value was changed from 10 to 100, and finding it in a "Merged from X" commit with the history of why the value was changed from 10 to 100. I don't often (ever?) browse the history, but I _do_ regularly search the history using tooling, (git log | grep ), and more is more in that case, even if the history isn't perfect.

That just sounds like a bad squash.

If the original commits are: - Change X to 10 by Foo - Change X to 100 by Bar - Change X to 50 by Baz

And that gets squashed into `Change X to 50 by Baz`, you lose the context as to why Foo and Bar changed it, and the values. If I need to go investigate an issue with X, I'd rather thave the history of all the changes.

Re: Fortunately, I don't squash my commits

#263

Post by maccard »

saagarjha wrote: post #220
maccard wrote: post #41

Earlier quoted context omitted.

That's much better than looking at a file in a 300 file commit and seeing "merged from XXXX" with no information as to why that one line was changed. I'd much rather spend 30 seconds parsing through the 10 yak shaving commits than have to go trawling through old commits on a file to find the most likely owner of it to ping on slack.

You’re creating a false dichotomy. When people say “squash your commits”, the don’t mean “squash your entire repo into one commit”, they mean “get rid of you ‘typo’, ‘typo fix’ commits”. Your commits should still be small and self-contained.

Actually I think you're creating a false dichotomy. How many people are commiting dozens of "typo/fix build" commits and then squashing just those? In reality people are squashing the iteration process of "add an X, add a Y, remove the X because it didn't work, and add a Z instead of an X and Y" into "Add a Z"

If you're simply talking about removing "fix typo" commits, then just don't. Just ignore them. You don't need them, but someone might. They're not hurting you?

Re: Fortunately, I don't squash my commits

#264

Post by mmis1000 »

matheusmoreira wrote: post #109
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…

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.

Indeed it is just a normal commit that has extra parent commit…

Git commit is always a standalone item that linked to parent commits. The actual content can be completely unrelated to parent commmits if you must do.(but what is the point of doing this?)

A merge commit is just a commit that has more than one parent.

Re: Fortunately, I don't squash my commits

#265

Post by ezst »

LanternLight83 wrote: post #186
matheusmoreira wrote: post #148

Earlier quoted context omitted.

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.

I've always been frustrated by losing my topic branches once they're merged and deleted, but can't bring myself to clutter my local branches keeping them around, to the point of tagging them just to keep track- I like the sound of your argument and will look into how fast-forward effect my commit history vs. a merge commit, thx c:

This is where you realize that what's killing git is that git has no concept of branches whatsoever. Such a merge isn't "merging A into B (plus shove metadata as string into the commit message)", it is "merging A and B together", which is topologically identical, but semantically very distinct.

That's why Mercurial (esp. with evolve and topics) has forever my preference over git.

Re: Fortunately, I don't squash my commits

#266

Post by twic »

xorcist wrote: post #231
twic wrote: post #206

Earlier quoted context omitted.

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.

They're the same technical operation, but they're used in different ways, and it's the difference in use that matters. It's useful to be able to distinguish them. It's never too late to improve our terminology! How long had git diff --cached been around when git diff --staged was introduced?

Re: Fortunately, I don't squash my commits

#267

Post by [deleted] »

SassyGrapefruit wrote: post #255
jkubicek wrote: post #246

Earlier quoted context omitted.

Having fine-grained commits and having a clean git history aren't mutually exclusive. If you create and submit small PRs and git-squash those PRs into the main branch, you'll get the best of both worlds. FWIW, the way I use git results in me committing a lot . I treat it as, essentially a save point that I can undo to if I need to. The history for my personal branches is a mess of broken tests and false-starts on cod…

>If you create and submit small PRs and git-squash those PRs into the main branch, you'll get the best of both worlds. I definitely advocate for this. But I've worked some at some spots with "never squashers" that deliver every PR as 119 commits and tell me this yarn about "the time having all those commits totally saved their bacon". I've just never regretted squashing my commits into something manageable.

[deleted]

Re: Fortunately, I don't squash my commits

#269

Post by Nursie »

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

Surely this is why we have things like release tags and snapshots of previous versions?

Unpicking individual features is rarely simple even if you have got your git repo into an immaculate state, as things are interdependent.

Post reply on HN