[eru]

> 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_]

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]

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]

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

[globular-toast]

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.

[eru]

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.

[WorldMaker]

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.

[eru]

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

[mjd]

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.

[Supermancho]

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.

[baq]

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

[eru]

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.

[WorldMaker]

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