3 ms·
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 somethi
by geofft 5y ago
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.)
- a-dub 5y agoi think what you (and the OP) are describing goes beyond making merges more robust to nonfunctional changes by using something like an AST representation. making text edits apply cleanly is one part of the problem, but as the OP notes, the harder part of these merges is actually when interfaces stay the same but behavior changes. i think that to solve that, you'd need some kind of static analyzer that could jump from changed lines/syntax to execution paths and then to diffs of them. i bet there are some cool papers out there on trying to do this... but, this is essentially a restatement of the halting problem, so building something that is guaranteed to be correct using only static analysis may be impossible. (but this does not preclude a solution that might be good enough)
- catlifeonmars 5y agoWell in an ideal world, Liskov’s substitution principle applies and you only ever care about interface changes.
- catlifeonmars 5y agoI’m this same world, you don’t make breaking changes without a new version of the interface. I like living in fantasy land :)
- bsmedberg 5y agoIn theory you can plug any three-way merge tool into git. I’d love to see merge tools that are syntax aware and can merge asts more than line text.