> There's bonus information too. If a commit is not mentioned in the report, then it only changed files that didn't change in any other commit. That means that in a rebase, I can move that commit literally anywhere else in the sequence without creating a conflict. Only the commits in the report can cause conflicts if they are reordered.

This is only true in the textual level.

Semantically, re-shuffling commits like this can still cause conflicts. Ie it can break your tests. Not at the end, but for the intermediate commits.

▲

_dark_matter_ 12 hours ago | parent [-]

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

▲

mcintyre1994 8 hours ago | parent | next [-]

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.

	▲	eru 7 hours ago \| parent [-]
		Yes, but at least git bisect lets you mark a commit as 'skip' in these cases.

▲

eru 7 hours ago | parent | prev | next [-]

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.

▲

mjd 12 hours ago | parent | prev | next [-]

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.

▲

baq 8 hours ago | parent [-]

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

	▲	eru 7 hours ago \| parent [-]
		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.

▲

globular-toast 7 hours ago | parent | prev [-]

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.