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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html