4 ms·

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

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

mjd 1y ago
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 1y ago
  …and that’s why squash merge should be the default setting in PRs.
  - eru 1y ago
    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 1y ago
    You can `git bisect --first-parent` just fine without needing to squash.
- Supermancho 1y ago
  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.
mcintyre1994 1y ago
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 1y ago
  Yes, but at least git bisect lets you mark a commit as 'skip' in these cases.
eru 1y ago
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 1y ago
  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.
globular-toast 1y ago
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 1y ago
> 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 1y ago

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 1y ago
…and that’s why squash merge should be the default setting in PRs.
- eru 1y ago
  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 1y ago
  You can `git bisect --first-parent` just fine without needing to squash.
Supermancho 1y ago
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.

mcintyre1994 1y ago

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 1y ago
Yes, but at least git bisect lets you mark a commit as 'skip' in these cases.

eru 1y ago

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 1y ago
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.

globular-toast 1y ago

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 1y ago

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