Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 26, 2018, 16:56 UTC
- Message-ID
- <xmqqtvomq6kd.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <xmqq4lgmubi8.fsf@gitster-ct.c.googlers.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 22 quoted lines
> Stefan Beller <sbeller@google.com> writes: > >>> * js/range-diff (2018-07-25) 21 commits > >> I think the current coloring is good enough to ship, but it still has >> errors around corners, for example introduction of new files, >> having lines in the inner diff as: >> >> diff --git a/Makefile b/Makefile >> --- a/Makefile >> +++ b/Makefile >> >> will be colored white/red/green (in that order), but in the outer diff >> these are all "context", but as these specific context lines happen >> to start with +/- we color them. >> If we want to be perfect, we rather need to parse&understand >> the inner diff on a more detailed level, but I would argue to leave >> that to a later stage for another volunteer to step in and cleanup. > > I think the primary part of coloring i.e. "white is common, green is > added, red is removed" together with "bold is new, dimmed is old" is > quite usable and not broken.
I just compared the output from the original tbdiff and the dual color mode of range-diff; especially with that "new round is bold, old round is dimmed", I find that the coloring makes it easier to spot what kind of each line is than what tbdiff did.
Dscho, good job on that.