2 ms·
Is keeping history of textual changes better than (also) keeping history of semantic changes? We focus so much on the representation (text in a programming lang
by vladms 3y ago
Is keeping history of textual changes better than (also) keeping history of semantic changes? We focus so much on the representation (text in a programming language) that we might miss capturing intentions (when clear).
I love GIT and GIT is great for what it does, but most of the times I feel that what I need from a history is different than just text changes. Two simple examples: white-space changes and variable name changes could be ignored for some cases (of course, not for all, but that's the trick).
Such changes might be built on top of git (and some are today), but at some point new requirements might mean a different system.
- radiospiel 3y agoAt least for whitespace changes git should have you covered --ignore-space-at-eol Ignore changes in whitespace at EOL. -b --ignore-space-change Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent. -w --ignore-all-space Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none. --ignore-blank-lines
- hawski 3y agoI will play a devil's advocate. What about white space sensitive language like Python (that's one of things I hate about the language)? Diff also gets easily confused, because its context window is pretty small.
- hnfong 3y agoI'm repeating my comment in a sibling thread, but I think it's worth repeating (paraphrasing) - (A) If the thing you have in mind can be inferred by looking at two commits, then you don't have to record the intention of the changes into the version control system because you can compute it later when needed. (B) If the thing you have in mind can't be reliably inferred by looking at two commits, then you need some other way to tell the version control system about your intention. For example, if you're just re-indenting a python source file, are you going to: 1. expect the system to automatically/heuristically realize you're just re-indenting it --> see (A) 2. explicitly tell the system that you've reindented it when making the commit --> are you sure you're bothered to do that? 3. Consistently and exclusively use a specialized IDE that records all your actions and transforms it to the corresponding intentions as recognized by the version control system?
- pjc50 3y agoThere are alternate diff algorithms that can be selected within even standard git diff. It's just stuck on the traditional one as the default.
- hnfong 3y agoKeeping the "intention" of the changes in the system only works if you actually bother to record or annotate the intention while making the commit. If your idea is to use heuristics to automatically infer intention during commit time and record it into the system, then obviously you can also do that in git after the fact by comparing two commits and running the same heuristic. In most cases (except file move?), I doubt the intention of the changes are so easily/cleanly captured. You'll probably need to have some deep IDE integration (eg. so it knows you actually renamed all your variables using the refactor tool). I can't see that having widespread application at all.
- vladms 3y agoSimple thing that gets lost: someone adds very long comment on one line (maybe has word wrapping on); someone formats the comment to be on multiple lines; diff will be a mess even if there is no text difference in the actual comment. One thing to investigate would be to include AST (abstract syntax tree) concepts in the source control or tools (although for comments might not solve the issue). Renaming a variable, moving a function around and other cases would be caught by an AST aware source control, but they are not today.