Hi Junio, On Mon, 21 May 2018, Junio C Hamano wrote: > I've been using both branch-diff and tbdiff while comparing rerolled > topics before accepting them. One obvious difference between the two is > that the speed to compute pairing is quite different but that is > expected ;-) Yep. It is also expected that the branch --diff actually works without you having to make sure that the Python modules numpy and hungarian are built correctly (which you Linux folks couldn't care less about because it is done for ya). I spent such a lot on time trying to get it to work on Windows that it probably only now reaches parity with the time I spent on implementing branch --diff. > Another difference that is somewhat irritating is that a SP that > leads a context line in a diff hunk that is introduced in the newer > iteration is often painted in reverse, and I do not know what aspect > of that single SP on these lines the branch-diff wants to pull my > attention to. Right. This is due to the fact that the diff does not realize that it looks at pre/post images being diffs. And hence it does not understand that the single space indicates a context line and is therefore not a whitespace error before the tab. > https://pasteboard.co/Hm9ujI7F.png > > 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. > We can use --dual-color mode to unsee these but it is somewhat > frustrating not to know what the branch-diff program wants to tell > me by highlighting the single SPs on these 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? Ciao, Dscho
