4 ms·

> Since it's aimed at line-oriented code, it does line-based diffs You can do word diffs with git: git diff --word-diff=color

DannyBee 13y ago
It's still recreating a word based diff from a line based diff. See diff.c line 793 for how it works.
- azernik 13y ago
  It may be doing that conversion, but the conversion works. For example, committing the following text (with line breaks), then joining it all into one line, shows no differences when using 'git diff --word-diff'. Test the first. This will check if reflowing text actually produces git word-diff weirdness, or if it's actually decent. The line does get reproduced on the terminal (a line diff was seen), but no text is shown in green or red to indicate an actual change.
  - mjn 13y ago
    Just checked with the old and new versions of Title_09.txt and you're right, --word-diff does the right thing. It echoes all the changed lines to the terminal, but it only marks up (and colors, in color mode) the changed words: [-Section 2 of act-]{+Act+} July 30, 1947, ch. 392, {+Sec. 2,+} 61 Stat. 674, provided that Wonder if there's a way to enable that behavior on GitHub? And/or to generate repository activity statistics based on changed words rather than changed lines?
  - DannyBee 13y ago
    Sure, but this particular test tells you nothing. You need one where the "line diff" has identified the wrong set of changes (IE it has decided two sets of text look close enough that one is really a change into the other, even though that's not what historically happened).
    - azernik 13y ago
      That is never the error I see in line-based diffs; because they're taking a much larger chunk of text to be atomic and treat irrelevant characters as relevant, they tend to give false positives (seeing two lines as completely different when in fact they're slightly modified versions of each other; or seeing two blocks of text as different when one is a reflowed version of the other.)

DannyBee 13y ago

It's still recreating a word based diff from a line based diff. See diff.c line 793 for how it works.

azernik 13y ago
It may be doing that conversion, but the conversion works. For example, committing the following text (with line breaks), then joining it all into one line, shows no differences when using 'git diff --word-diff'. Test the first. This will check if reflowing text actually produces git word-diff weirdness, or if it's actually decent. The line does get reproduced on the terminal (a line diff was seen), but no text is shown in green or red to indicate an actual change.
- mjn 13y ago
  Just checked with the old and new versions of Title_09.txt and you're right, --word-diff does the right thing. It echoes all the changed lines to the terminal, but it only marks up (and colors, in color mode) the changed words: [-Section 2 of act-]{+Act+} July 30, 1947, ch. 392, {+Sec. 2,+} 61 Stat. 674, provided that Wonder if there's a way to enable that behavior on GitHub? And/or to generate repository activity statistics based on changed words rather than changed lines?
- DannyBee 13y ago
  Sure, but this particular test tells you nothing. You need one where the "line diff" has identified the wrong set of changes (IE it has decided two sets of text look close enough that one is really a change into the other, even though that's not what historically happened).
  - azernik 13y ago
    That is never the error I see in line-based diffs; because they're taking a much larger chunk of text to be atomic and treat irrelevant characters as relevant, they tend to give false positives (seeing two lines as completely different when in fact they're slightly modified versions of each other; or seeing two blocks of text as different when one is a reflowed version of the other.)