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

[PATCH] document behavior of empty color name

From
Jeff King <peff@peff.net>
Date
Feb 2, 2017, 12:42 UTC
Message-ID
<20170202124238.53k74cedpp2rcmzo@sigill.intra.peff.net>
In-Reply-To
<20170202091615.GA22337@ash>
On Thu, Feb 02, 2017 at 04:16:15PM +0700, Duy Nguyen wrote:
> > I hadn't heard anything back,
> 
> Sorry I was accidentally busy during Luna new year holiday.
No problem. That sounds much more fun than working on Git. :)
Show 13 quoted lines
> > -	if (!len)
> > -		return -1;
> > +	if (!len) {
> > +		dst[0] = '\0';
> > +		return 0;
> > +	}
> >  
> >  	if (!strncasecmp(ptr, "reset", len)) {
> >  		xsnprintf(dst, end - dst, GIT_COLOR_RESET);
> 
> I wonder if it makes more sense to do this in builtin/config.c. The
> "default value" business is strictly git-config command's. The parsing
> function does not need to know. Maybe something like this?

I don't think so. The default value is a git-config thing, but you would want to be able to do the same thing in a config file. For example, to disable coloring entirely for part of the diff, you could do:

  [color "diff"]
  meta = ""
> This is also a good opportunity to document this behavior in
> git-config.txt, I think.
Yeah. Maybe:
-- >8 --
Subject: [PATCH] document behavior of empty color name

Commit 55cccf4bb (color_parse_mem: allow empty color spec, 2017-02-01) clearly defined the behavior of an empty color config variable. Let's document that, and give a hint about why it might be useful.

It's important not to say that it makes the item uncolored, because it doesn't. It just sets no attributes, which means that any previous attributes continue to take effect.

Signed-off-by: Jeff King <peff@peff.net>
---
 Documentation/config.txt | 3 +++
 1 file changed, 3 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 33a007b52..49b264566 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -170,6 +170,9 @@ The position of any attributes with respect to the colors
 be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`,
 `no-ul`, etc).
 +
+An empty color string produces no color effect at all. This can be used
+to avoid coloring specific elements without disabling color entirely.
++
 For git's pre-defined color slots, the attributes are meant to be reset
 at the beginning of each item in the colored output. So setting
 `color.decorate.branch` to `black` will paint that branch name in a
-- 
2.11.0.948.gca97da533
Previous: Duy NguyenNext: Duy Nguyen
Message 5 of 11 in “What's cooking in git.git (Jan 2017, #06; Tue, 31)”
  1. Junio C HamanoJan 31, 2017
  2. color_parse_mem: allow empty color specJeff King, Feb 1, 2017
  3. Jacob KellerFeb 1, 2017
  4. Duy NguyenFeb 2, 2017
  5. document behavior of empty color nameJeff King, Feb 2, 2017
  6. Duy NguyenFeb 3, 2017
  7. Jeff KingFeb 3, 2017
  8. Junio C HamanoFeb 3, 2017
  9. Jeff KingFeb 4, 2017
  10. Patrick SteinhardtFeb 1, 2017
  11. Junio C HamanoFeb 1, 2017

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.