Re: make git diff output easier to read - use better diff heuristics

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Feb 13, 2018, 22:41 UTC
Message-ID: <CAMy9T_FHhXMJTTHR3jg-SGab-1Rgy3FScMxeCUcUjnPfCZEJiw@mail.gmail.com>
In-Reply-To: <CAOmC-AnXD=eSphS=TK4v72tSYDYEV2cgu_EsP4kgNGR=7yre8w@mail.gmail.com>

On Tue, Feb 13, 2018 at 7:25 PM, Σπύρος Βαζαίος <sbazaios@gmail.com> wrote:

Show 6 quoted lines

> While I din't have the experience to express an opinion on this
> matter, I have to say that the --no-indent-heuristic that Jeff
> suggested worked great.
> There were more than a handful of cases that this issue happened in my
> diff file (all were the same: #endif followed by #ifdef).
> Oh, and the language is C indeed.

The "indent heuristic" algorithm that Git now uses by default is nothing more than that—a heuristic—so it can be fooled. It bases its decision on the locations of blank lines and the indentations of non-blank lines. In the vast majority of cases it gives the same or better results than the old algorithm, but there are some cases, like yours, where it gives aesthetically less pleasing (though still correct) results.

The algorithm usually handles C code well, but it tends to be confused by preprocessor directives, because they are not indented like typical code. It might be possible to tweak the weights to get it to handle preprocessor directives better, but that causes it to do worse on other, more common things like Python code (where blocks are preceded but not followed by a line with lesser indentation).

Doing significantly better probably would require some amount of language-awareness, but that's a bigger job than I was willing to take on.

Michael