Hi Junio, On Tue, 22 May 2018, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schinde...@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. > 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. > > 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
