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.
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:
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.git blamewon’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 blameisn’t even the right tool for the job anyway,git log -Lis.