Re: [PATCH 00/18] Add `branch-diff`, a `tbdiff` lookalike

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 1, 2018, 08:28 UTC
Message-ID: <nycvar.QRO.7.76.6.1806011023430.82@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqmuwszcs4.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Tue, 22 May 2018, Junio C Hamano wrote:

Show 12 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> In the picture, the three pre-context lines that are all indented by
> >> a HT are prefixed by a SP, and that is prefixed by a '+' sign of the
> >> outer diff.
> >
> > Yep, that's exactly it.
> >
> > The way tbdiff did it was to parse the diff and re-roll the coloring on
> > its own. I am not really keen on doing that in `branch --diff`, too.
> 
> Are you saying that these are "whitespace errors" getting painted?

Indentation errors, to be precise. Yes.

Show 5 quoted lines

> It is somewhat odd because my whitespace errors are configured to be
> painted in "reverse blue".  Perhaps you are forcing the internal
> diff not to pay attention to the end-user configuration---which
> actually does make sense, as reusing of "git diff" to take "diff of
> diff" is a mere implementation detail.

It may have been the case before I introduced that call to git_diff_ui_config(), but that happened after -v2, and I did not contribute -v3 yet.

> In any case, the "whitespace errors" in "diff of diff" are mostly
> distracting.

Precisely. That's why I tried to suppress them in --dual-color mode.

I did not try to suppress them in --color (--no-dual-color) mode, as I find that mode pretty useless.

Show 16 quoted lines

> > I was wondering from the get-go whether it would make sense to make
> > --dual-color the default.
> >
> > But now I wonder whether there is actually *any* use in `--color` without
> > `--dual-color`.
> >
> > What do you think? Should I make the dual color mode the *only* color
> > mode?
> 
> Sorry but you are asking a good question to a wrong person.
> 
> I normally do not seek much useful information in colored output, so
> my reaction would not be very useful.  Non dual-color mode irritates
> me due to the false whitespace errors, and dual-color mode irritates
> me because it looks sufficiently different from tbdiff output that I
> am used to see.

Do you use --dual-color normally?

I derive *a ton* of information from the colored diff. It really helps me navigate the output of range-diff very quickly.

I ask whether you use --dual-color because in that case I would consider scrapping the way I handle color right now and try to imitate tbdiff's way. But that would lose whitespace error coloring *altogether*. So I, for one, would be unable to see where a subsequent patch series iteration fixes whitespace errors of a previous iteration.

Ciao, Dscho