[PATCH v3 0/2] gitk --color-words

From: Thomas Rast <trast@student.ethz.ch>
Date: Apr 12, 2010, 13:07 UTC
Message-ID: <cover.1271077334.git.trast@student.ethz.ch>
In-Reply-To: <s2kfc339e4a1004051153yc950b858lb919740f0de80e9@mail.gmail.com>

During development an unrelated gitk diff parsing bug hit me, which is the new 2/3. I think it should go in maint if the patch turns out to be correct, but I'd like to have an ACK from Jens first.

Junio C Hamano wrote:

> I also think --color --word-diff=plain could show "{+new+}" in green and
> "[-old-]" in red and that may make things more consistent.

So here's a patch that does that. I may be overdoing the "generic diff style" code a bit, but it makes for slightly nicer code.

I similarly extended the support in gitk to have two different modes. My use of the dropdown is again sheer voodoo and works merely by accident...

I also taught gitk to not show the option and not parse the command-line options unless the git version is at least v1.7.2, which I expect will be the version that has the underlying diff support.

BTW:

Miles Bader wrote:

> For some reason, even though I can see the red and green well enough,
> I find the current --color-words output hard to parse.
> The use of _only_ color to distinguish old/new somehow doesn't jive
> with my brain...

I set my diff colors to bold red/blue which makes the changed words very visible even in light conditions where green is very hard to tell from black (sitting outside in the sun or so).

> I find _highlighting_ using color very useful, but I think using
> syntax and color together is better than using just color.

Well, I for one find the extra markup *very* confusing because I need to mentally untangle it from the actual content...

Thomas Rast (3):
  diff: add --word-diff option that generalizes --color-words
  gitk: do not parse "  >" context as submodule change
  gitk: add the equivalent of diff --color-words