4 ms·

> Which is not the same as what you may have actually done to change old file into new one. I’ve seen this with methods: I add a method, so I expect to see the

> Which is not the same as what you may have actually done to change old file into new one. I’ve seen this with methods: I add a method, so I expect to see the whole new method in the diff. But actually the diff looks as if I’ve inserted something just before the closing brace of the existing method above the new one. I’ve learned to detect this when reading diffs but a nice display would be, err, nice.

Sesse__ 3y ago
This is sometimes called a “slider”. Difftastic has special logic to try to deal with sliders and get closer to what you want.
- hibbelig 3y ago
  Oh yes, I need to remember to show diffs using difftastic.
OJFord 3y ago
Git has a few (configurable) diff algorithms; 'histogram' is more readable (IMO, but that's the design goal - or rather is of 'patience' which it extends/speeds up) than the default Myers algorithm, but it does still suffer from the issue you describe IME. Paper comparing Myers and histogram: https://link.springer.com/article/10.1007/s10664-019-09772-z https://link.springer.com/article/10.1007/s10664-019-09772-z Naïvely it seems like it should be not that hard to fix (be less greedy?) or even that it's an example of a case where the algorithm should be less smart: it's such a common case, hardcode paren chars for some kind of exception or second pass. But that is a naïve take, I've never looked at the algorithm or source code at all.
emmelaich 3y ago
I think you want the 'patience' option... --patience Generate a diff using the "patience diff" algorithm.
yencabulator 3y ago
You'll probably enjoy the patience or histogram diff algorithms. See https://luppeng.wordpress.com/2020/10/10/when-to-use-each-of-the-git-diff-algorithms/ https://luppeng.wordpress.com/2020/10/10/when-to-use-each-of... for more. [diff] algorithm = "histogram" You can also teach git to always show e.g. function names in the diff hunk heading. For example, to always show previous Markdown heading: ~/.config/git/config [diff "markdown"] xfuncname = "^(#+\\s*.*)" ~/.config/git/attributes *.md diff=markdown whitespace=-blank-at-eol
- hibbelig 3y ago
  Thank you; I have configured histogram and we will see.

Sesse__ 3y ago

This is sometimes called a “slider”. Difftastic has special logic to try to deal with sliders and get closer to what you want.

hibbelig 3y ago
Oh yes, I need to remember to show diffs using difftastic.

OJFord 3y ago

Git has a few (configurable) diff algorithms; 'histogram' is more readable (IMO, but that's the design goal - or rather is of 'patience' which it extends/speeds up) than the default Myers algorithm, but it does still suffer from the issue you describe IME. Paper comparing Myers and histogram: https://link.springer.com/article/10.1007/s10664-019-09772-z https://link.springer.com/article/10.1007/s10664-019-09772-z Naïvely it seems like it should be not that hard to fix (be less greedy?) or even that it's an example of a case where the algorithm should be less smart: it's such a common case, hardcode paren chars for some kind of exception or second pass. But that is a naïve take, I've never looked at the algorithm or source code at all.

emmelaich 3y ago

I think you want the 'patience' option... --patience Generate a diff using the "patience diff" algorithm.

yencabulator 3y ago

You'll probably enjoy the patience or histogram diff algorithms. See https://luppeng.wordpress.com/2020/10/10/when-to-use-each-of-the-git-diff-algorithms/ https://luppeng.wordpress.com/2020/10/10/when-to-use-each-of... for more. [diff] algorithm = "histogram" You can also teach git to always show e.g. function names in the diff hunk heading. For example, to always show previous Markdown heading: ~/.config/git/config [diff "markdown"] xfuncname = "^(#+\\s*.*)" ~/.config/git/attributes *.md diff=markdown whitespace=-blank-at-eol

hibbelig 3y ago
Thank you; I have configured histogram and we will see.