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

Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)

From
Aaleksi.aalto@iki.fi <aleksi.aalto@iki.fi>
Date
Dec 6, 2010, 00:54 UTC
Message-ID
<alpine.SOC.2.00.1012060235180.18993@kekkonen.cs.hut.fi>
In-Reply-To
<7v8w04vvvr.fsf@alter.siamese.dyndns.org>
On Sun, 5 Dec 2010, Junio C Hamano wrote:
Show 19 quoted lines
> Jeff King <peff@peff.net> writes:
>
>> On Sat, Dec 04, 2010 at 10:30:21PM -0800, Junio C Hamano wrote:
>>
>>> * aa/status-hilite-branch (2010-11-18) 1 commit
>>>  - status: show branchname with a configurable color
>>>
>>> I am indifferent/uninterested; I don't see anything wrong with it, but I
>>> do not find coloring the field particularly useful myself.
>>
>> I am not particularly interested, either, but FWIW, the gitcommit syntax
>> highlighting that ships with vim does highlight this, so there are at
>> least other people who think this is a good idea.
>
> As you already know, when I say "'Meh' personally", I am not saying "I
> want to forbid others to want it".
>
> How does vim highlight the other parts of that particular line?  Does it
> keep them intact, or paint them in some other color?

The default colorscheme results in the branchname being colored with a different color than the rest of the header. Also the texts "Changes to be committed:" and "Untracked files" are colored with the same color. However with some other colorschemes, these texts have a different color from the branchname.

Show 12 quoted lines
> I had this suspicion that the class of people who choose a non default
> status.header color and the class of people who choose plain there (or
> have been happy with the default) expect different things.  The former
> prefer louder output, different pieces of information painted in different
> colors to help them chromatically distinguish them.  The latter (including
> myself) favor subdued output, without too many colors distacting them
> while reading the output.
>
> This suspicion further led me to think that the former would want this new
> feature to paint the branch name in a color different from status.header
> color, while the latter would want it in plain.  So the default of "plain"
> would be a win for both audiences.
This reasoning sounds good to me.
:Aga
Previous: Junio C HamanoNext: Jeff King
Message 4 of 27 in “What's cooking in git.git (Dec 2010, #01; Sat, 4)”
  1. Junio C HamanoDec 5, 2010
  2. Jeff KingDec 5, 2010
  3. Junio C HamanoDec 5, 2010
  4. aleksi.aalto@iki.fiDec 6, 2010
  5. Jeff KingDec 9, 2010
  6. Junio C HamanoDec 10, 2010
  7. Yann DirsonDec 5, 2010
  8. Junio C HamanoDec 5, 2010
  9. Yann DirsonDec 6, 2010
  10. Miles BaderDec 6, 2010
  11. Yann DirsonDec 6, 2010
  12. Miles BaderDec 6, 2010
  13. Yann DirsonDec 6, 2010
  14. Miles BaderDec 6, 2010
  15. Yann DirsonDec 6, 2010
  16. Matthieu MoyDec 6, 2010
  17. Junio C HamanoDec 10, 2010
  18. aleksi.aalto@iki.fiDec 5, 2010
  19. Patrick RouleauDec 5, 2010
  20. Erik Faye-LundDec 5, 2010
  21. Junio C HamanoDec 5, 2010
  22. Michael J GruberDec 5, 2010
  23. Junio C HamanoDec 5, 2010
  24. Michael J GruberDec 6, 2010
  25. Thiago FarinaDec 6, 2010
  26. t9010 broken in pu [Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)]Thomas Rast, Dec 8, 2010
  27. Jonathan NiederDec 8, 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.