Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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? 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. In any case, the "whitespace errors" in "diff of diff" are mostly distracting. > 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.
