Squashed commits are not atomic, unless the MR is so tiny that it logically fits into one commit. This is often not the case, though. It is frequently the case that the overall task requires modifying multiple different systems, which should themselves be their own commits, with tests for changes added to the same commit that makes the change.

A well-crafted MR should tell a story in its commits, with changes proceeding logically from one another.

It seems to me what you are really arguing against is poorly crafted history, which I fully agree is something to be stamped out.

To address the specific commands you mentioned:

That's... really besides the point of git bisect. It's binary search to find bad commits. If the selected midway point happens to be a formatting commit (which I'd argue should really be handled by pre-commit hooks anyway) and that commit is broken, it just means that the search proceeds to the midway point between that commit and the known good commit.
You can revert a range of commits, but the point of crafting a quality history is not doing things like having separate commits for tests. Tests belong with the code that it's testing.
First off, any reasonable usage of git will have ticket/issue numbers in the commits that you can use to look up the full task information. But also, git blame won't show the rename commit if it's a separate commit from any changes (which it absolutely should be, due to how git handles renames). And finally, if you care about getting more detail about why the code is the way it is, git blame isn't even the right tool for the job anyway, git log -L is.

[–] pupbiru@aussie.zone 1 points 4 days ago* (last edited 4 days ago) (1 children)

Squashed commits are not atomic … overall task requires modifying multiple different systems

that’s why monorepos exist

i’d say squashed commits aren’t always atomic, but this is one of the biggest reasons people add the complexity of a monorepo: if changes cross multiple systems, ideally their merge/revert should be an atomic operation

you either have deployment complexity (ensuring the feature is in all deployed systems before switching over), code complexity (dealing with the feature only maybe exiting in parts of the system), or repo complexity (where tools manage a monorepo and thus commits and PR/MRs are atomic across your system)

[–] expr@piefed.social 1 points 4 days ago (1 children)

Monorepos don't really change anything. Squashed commits are still not atomic, unless the MR is small enough to fit into a single logical commit. Changes made to say, a database query are distinct from changes made to route handling, yet both might be needed for the overall feature. They don't belong in the same commit in history.

[–] pupbiru@aussie.zone 1 points 3 days ago

hard disagree on what belongs in the same commit history… a single merge should be an entire feature, and your commit history should read like a change log