git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/2] diff: add --word-diff option that generalizes --color-words

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 5, 2010, 18:46 UTC
Message-ID
<7v6345pwjw.fsf@alter.siamese.dyndns.org>
In-Reply-To
<201004051220.47400.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
Show 9 quoted lines
>> I think it is a bug that "git show --word-diff" gives the colored format
>> output when I have "color.ui" configuration.
>> 
>> Even though I may have "color.ui = auto" in the configuration, I am
>> telling the command to do a --word-diff, not --color-words, from the
>> command line, and that should override color.ui settings.
>
> I don't really see why the user would forfeit the convenience and
> readability of a color-words diff when the terminal supports colors.

There is one difference between other uses of colors and color-words, but I can imagine that ordinary people may not have even realized nor thought about it.

To people who are somewhat but not completely color-challenged (like myself), it still helps to paint hunk headers in a color that is different from the body text to make the boundary of each hunk more visible. Even without the perception of exact color/hue, the contrast alone helps in that case.

The body of the diff is painted in deleted and added colors; the color is used only as a way to additionally enhance the output, while still keeping the plus/minus/SP at the leftmost column. Even to somebody who is completely color challenged, the necessary information is still there.

Compare --color-words with these. The output uses color as the _only_ way to say which words appear before and after. The contrast among the three colors used for the plain body, deleted and added text may still help, or it may not, to a partially color challenged person.

I also happen to see "--word-diff=color" more as just a customization to the "plain" output formatting to say "use these byte sequences that happen to be ANSI color codes, instead of '{+', '+}', etc." than as a part of what the ui.color switch wants to specify, which is "are various parts of the output colored to further help distinguishing them visually?"

So color me somewhat biased, but there is a case where the suggestion in the message you are responding to makes a difference.

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

Previous: Thomas RastNext: Miles Bader
Message 5 of 15 in “gitk --color-words”
  1. 0/2 gitk --color-wordsThomas Rast, Apr 4, 2010
  2. 1/2 diff: add --word-diff option that generalizes --color-wordsThomas Rast, Apr 4, 2010
  3. Junio C HamanoApr 5, 2010
  4. Thomas RastApr 5, 2010
  5. Junio C HamanoApr 5, 2010
  6. Miles BaderApr 5, 2010
  7. 0/2 gitk --color-wordsThomas Rast, Apr 12, 2010
  8. 1/3 diff: add --word-diff option that generalizes --color-wordsThomas Rast, Apr 12, 2010
  9. Junio C HamanoApr 12, 2010
  10. Thomas RastApr 13, 2010
  11. 2/3 gitk: do not parse " >" context as submodule changeThomas Rast, Apr 12, 2010
  12. gitk: do not parse " >" context as submodule changeThomas Rast, Apr 12, 2010
  13. 3/3 gitk: add the equivalent of diff --color-wordsThomas Rast, Apr 12, 2010
  14. Thomas RastApr 6, 2010
  15. 2/2 gitk: add the equivalent of diff --color-wordsThomas Rast, Apr 4, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.