4 ms·

This would be really interesting to do with some sort of move-aware diff algorithm. Does anyone know if such a thing exists? Instead of getting lines removed +

This would be really interesting to do with some sort of move-aware diff algorithm. Does anyone know if such a thing exists? Instead of getting lines removed + lines added, there could be some sort of content aware diff algorithm that works with 'data chunks' at another granularity (lines = good for code, words ala diff --color-words = good for text) diff = fancy_diff(c1, c2) # diff ~ {'added':<int>, # 'removed':<int>, # 'changed':<int>, # 'moved':<int> } where `moved` represents # of `-` lines in diff that have an identical corresponding `+` line, and `changed` represents lines where 60%+ of - line matches the text in some + line. Using such a fancy_diff, moving a 200-line chunk of code from one source file to another source file won't show up as -200s and +200s, but as {'added':0,'removed':0,'moved':200} Looking at such "fancy diff" numbers will show more what's going on...

chatmasta 8y ago
Pretty sure git does this already by calculating a “similarity index”. So if you mv a file even without an explicit `git mv`, git will recognize it at commit time as a file in a different location. Perhaps this is presentational only, though; after all, a mv is fundamentally a delete and create. Not 100% sure on that though, nor am I sure if the same applies at the line level.
- ivan_ah 8y ago
  Yeah, I think the git "chunks" are quite large though. A big enough move (e.g. an entire file) will be recognized as a rename and reuse a pointer to the underlying blob, but anything paragraph-sized will be recorded as remove and an add. To be honest, I'm not sure if computing a fancy diff of the form {'added':<int>, 'removed':<int>, 'changed':<int>, 'moved':<int>} is a well defined problem because there are multiple ways one could interpret a given set of changes, e.g., is it a move with a small edit vs. and add and remove. We might need to define some "economy of diff" objective to optimize... something like Kolmogorov complexity for diffs?

chatmasta 8y ago

Pretty sure git does this already by calculating a “similarity index”. So if you mv a file even without an explicit `git mv`, git will recognize it at commit time as a file in a different location. Perhaps this is presentational only, though; after all, a mv is fundamentally a delete and create. Not 100% sure on that though, nor am I sure if the same applies at the line level.

ivan_ah 8y ago
Yeah, I think the git "chunks" are quite large though. A big enough move (e.g. an entire file) will be recognized as a rename and reuse a pointer to the underlying blob, but anything paragraph-sized will be recorded as remove and an add. To be honest, I'm not sure if computing a fancy diff of the form {'added':<int>, 'removed':<int>, 'changed':<int>, 'moved':<int>} is a well defined problem because there are multiple ways one could interpret a given set of changes, e.g., is it a move with a small edit vs. and add and remove. We might need to define some "economy of diff" objective to optimize... something like Kolmogorov complexity for diffs?