I agree with the author re Git as it exists right now, but this feels like an unsolved technical problem that ideally should be handled in your VCS than something to be worked around by social conventions not to do cleanups.
git blame, for instance, has the "--ignore-revs" and "--ignore-revs-file" options which let you specify some commits that can be ignored. This is a little helpful for the sort of code spelunking the author does (which I do very frequently), but it's a manual process. There's no built-in convention to Git for what this file should be named and how to have git blame pick it up automatically. Moreover, you have to create the commit in order to know what its revision is, which means that in squash/rebase workflows, you have to land the style cleanup on the target branch and only then can you add it to the ignore list.
One option that occurs to me is a special marker string to put in the commit message like "Git-Ignore-For-Blame: yes" or something. I'm not sure if there's a better way to do it.
More generically, if the commit is only swapping out tabs and spaces, "git blame -w" ought to take care of it. For more involved reformatting, git diff and git merge both have "ignore-all-space" modes, which will handle things like line breaks.
But really what you want for blames and cherry-picks, I think, is blames at the syntax level. The Git commands only know about lines - git blame runs on lines, git cherry-pick constructs diffs based on lines and tries to re-apply them, etc. But at the repository level there's nothing special about line breaks. Why can't we run git blame or cherry-pick on an AST, so that it operates regardless of formatting?
Are there tools that do this? (They don't need to be built into git; a third-party tool ought to be able to do this just fine.)
git blame, for instance, has the "--ignore-revs" and "--ignore-revs-file" options which let you specify some commits that can be ignored. This is a little helpful for the sort of code spelunking the author does (which I do very frequently), but it's a manual process. There's no built-in convention to Git for what this file should be named and how to have git blame pick it up automatically. Moreover, you have to create the commit in order to know what its revision is, which means that in squash/rebase workflows, you have to land the style cleanup on the target branch and only then can you add it to the ignore list.
One option that occurs to me is a special marker string to put in the commit message like "Git-Ignore-For-Blame: yes" or something. I'm not sure if there's a better way to do it.
More generically, if the commit is only swapping out tabs and spaces, "git blame -w" ought to take care of it. For more involved reformatting, git diff and git merge both have "ignore-all-space" modes, which will handle things like line breaks.
But really what you want for blames and cherry-picks, I think, is blames at the syntax level. The Git commands only know about lines - git blame runs on lines, git cherry-pick constructs diffs based on lines and tries to re-apply them, etc. But at the repository level there's nothing special about line breaks. Why can't we run git blame or cherry-pick on an AST, so that it operates regardless of formatting?
Are there tools that do this? (They don't need to be built into git; a third-party tool ought to be able to do this just fine.)