Hacker News Reader

Comment by _dark_matter_ | Hacker News Reader

This is why I no longer do atomic commits. I've just never had it be a benefit to walk through and guarantee that each commits tests and builds successfully. I so rarely back out changes that when I do, I test then that everything is working (and let's be honest, I back out usually at the PR level, not the commit).

View on HN

The other benefit of this is the git bisect workflow. If you can’t build your intermediate commits then you likely can’t easily identify whether a bug was present on that commit (for many types of bug), and you therefore can’t identify the commit that introduced the bug.

Yes, but at least git bisect lets you mark a commit as 'skip' in these cases.

I often wonder what the point of using git at all is at this point. I suppose it's just your interface to the source repo, but a massively overly capable one. If you don't care about atomic commits then you might as well just do `git commit -a --amend --no-edit` periodically (you could even do it on every save). Then the reflog is your "undo" but you don't pollute the shared repo with shit commits.

If you want atomic commits, you need to set up your CI/CD to ensure that each intermediate commit builds and passes tests.

Most pull requests should probably be squashed to appear as a single commit in the final history. But you should have the option of leaving history intact, when you want that, and then your CI/CD should run the checks as above.

You don't need squash here, though. If your CI/CD ensures that merge commits (PRs) are atomic/build and pass tests, you can `git bisect --first-parent` to just bisect your merge commits/integration points/pull requests, without tossing the other history from the git DAG.

> I've just never had it be a benefit to walk through and guarantee that each commits tests and builds successfully.

If you never look at individual commits in your history, you might as well squash them.

I agree. I decided years ago that that was a lot of work for little or no benefit.

It's enough for the tests to pass at each merge point.

…and that’s why squash merge should be the default setting in PRs.

Yes, it should be the default, but ideally you have the option of preserving history (for PRs where that makes sense) and then your CI/CD should also check that the individual commits build and pass tests.

In general, your CI/CD should make sure that each commit that appears in the 'public' history of main builds and passes tests.

You can `git bisect --first-parent` just fine without needing to squash.

I would say most workplaces have settled similarly.

Sit in draft until you're ready to use the CI - which you verified locally or run manually in draft, before convert to reviewable - then review, maybe tweak, merge.

Atomic commits would endanger me losing unfinished work or eventual dead-ends with no record. This seems inefficient.

Reply on news.ycombinator.com