5 ms·

If you have consistent code style and formatting this tool is unnecessary. I think that solution is better, you get a more consistent code base that is easier t

If you have consistent code style and formatting this tool is unnecessary. I think that solution is better, you get a more consistent code base that is easier to read for humans. (Also diffs will be faster to compute)

mcculley 5y ago
Even if you are consistent, having unchanged indented text show up differently is very clever. I often end up reviewing a diff that moves a basic block into a conditional branch and have to scan each line to see if it changed.
- jlokier 5y ago
  If you're using a language that doesn't depend on indentation (C, Java, Go, Rust etc), try "diff -b" or "git diff -b". The indented basic block won't show as a difference, only the start and end of the block.
  - hu3 5y ago
    interesting. Is -b equivalent to -Xignore-all-space in git?
mkdirp 5y ago
> If you have consistent code style and formatting this tool is unnecessary I disagree. I struggle to replicate it right now using a simple test, but I've seen the following rather infuriating and counter intuitive behaviour from Git/GNU diff. If you have a simple if statement such as: if (bla) { // do something } And you were to add another statement at the end, after the closing curly brace, e.g.: if (bla) { // do something } if (bla2) { // do something else } Git/GNU diff will sometimes show the following diff: diff --git 1/left 2/right index c2ea6f1..dc0e1c2 100644 --- 1/left +++ 2/right @@ -1,3 +1,6 @@ if (bla) { // do something +} +if (bla2) { + // do something else } This is basic example, but there's other similar things. For a simple change like the above, this isn't a huge issue, but for a bigger patch sets, it can take a minute to understand what is really going on.
- hoseja 5y ago
  There is an option [0] to use non-default but still built-in git diff algorithms that might yield better results. [0] https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---diff-algorithmpatienceminimalhistogrammyers https://git-scm.com/docs/git-diff#Documentation/git-diff.txt...
  - NateEag 5y ago
    I've used a few of the different git diff algorithms and still have had problems like these.
- lolc 5y ago
  Right, I frequently get angry at just how dumb diff really is. How it's greedy and can't recognize the best seams between blocks of code. But then when I think of simple rules that would improve the results, I see how they would lead to other problems in other places. So using syntax seems necessary.
kortex 5y ago
I run all python through `black` and `isort`; this is still a huge step up in my book in terms of readability and ergonomics compared to the standard `git diff` or gnu `diff`.

mcculley 5y ago

Even if you are consistent, having unchanged indented text show up differently is very clever. I often end up reviewing a diff that moves a basic block into a conditional branch and have to scan each line to see if it changed.

jlokier 5y ago
If you're using a language that doesn't depend on indentation (C, Java, Go, Rust etc), try "diff -b" or "git diff -b". The indented basic block won't show as a difference, only the start and end of the block.
- hu3 5y ago
  interesting. Is -b equivalent to -Xignore-all-space in git?

mkdirp 5y ago

> If you have consistent code style and formatting this tool is unnecessary I disagree. I struggle to replicate it right now using a simple test, but I've seen the following rather infuriating and counter intuitive behaviour from Git/GNU diff. If you have a simple if statement such as: if (bla) { // do something } And you were to add another statement at the end, after the closing curly brace, e.g.: if (bla) { // do something } if (bla2) { // do something else } Git/GNU diff will sometimes show the following diff: diff --git 1/left 2/right index c2ea6f1..dc0e1c2 100644 --- 1/left +++ 2/right @@ -1,3 +1,6 @@ if (bla) { // do something +} +if (bla2) { + // do something else } This is basic example, but there's other similar things. For a simple change like the above, this isn't a huge issue, but for a bigger patch sets, it can take a minute to understand what is really going on.

hoseja 5y ago
There is an option [0] to use non-default but still built-in git diff algorithms that might yield better results. [0] https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---diff-algorithmpatienceminimalhistogrammyers https://git-scm.com/docs/git-diff#Documentation/git-diff.txt...
- NateEag 5y ago
  I've used a few of the different git diff algorithms and still have had problems like these.
lolc 5y ago
Right, I frequently get angry at just how dumb diff really is. How it's greedy and can't recognize the best seams between blocks of code. But then when I think of simple rules that would improve the results, I see how they would lead to other problems in other places. So using syntax seems necessary.

kortex 5y ago

I run all python through `black` and `isort`; this is still a huge step up in my book in terms of readability and ergonomics compared to the standard `git diff` or gnu `diff`.