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:
quoted text
> 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:
quoted text
> 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).

quoted text
> 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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html