Re: [PATCH] Colourise git-branch output

3 messages, 3 authors, 2016-08-11 · open the first message on its own page

Re: [PATCH] Colourise git-branch output

From: Junio C Hamano <hidden>
Date: 2016-08-11 19:42:06

Sean [off-list ref] writes:
On Mon, 11 Dec 2006 22:10:08 +0000
Andy Parkins [off-list ref] wrote:
quoted
+int git_branch_config(const char *var, const char *value)
+{
+	if (!strcmp(var, "branch.color")) {
+		branch_use_color = git_config_colorbool(var, value);
+		return 0;
+	}
+	return git_default_config(var, value);
+}
As Junio already highlighted, the "branch.*" namespace is for actual
branch names.  This config option should go into "color.branch" or some
other spot.
I didn't.  And "branch.color = auto" is actually fine.

The problematic case is "branch.color.remote = purple".

Re: [PATCH] Colourise git-branch output

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-08-11 19:48:04


On Mon, 11 Dec 2006, Sean wrote:
Technically it is workable.. but why even start down the road of having
anything but branch names after a "branch."?   There has to be a better
spot for this variable, and it makes it more future proof, as you
highlighted.
I do agree with Sean, both for the stability reason, but perhaps even more 
because I personally think it would just be better to have a separate 
"[color]" subsection.

In fact, I'd almost prefer to see

	[color]
		diff = auto

over

	[diff]
		color = auto

exactly because once we have different things that take colorization 
arguments, it's just nicer to have them all together (and we already have 
"status", and now we're getting "branch" too.

Re: [PATCH] Colourise git-branch output

From: Sean <hidden>
Date: 2016-08-11 20:15:18

On Mon, 11 Dec 2006 17:11:24 -0800
Junio C Hamano [off-list ref] wrote:

quoted
As Junio already highlighted, the "branch.*" namespace is for actual
branch names.  This config option should go into "color.branch" or some
other spot.
I didn't.  And "branch.color = auto" is actually fine.

The problematic case is "branch.color.remote = purple".
Technically it is workable.. but why even start down the road of having
anything but branch names after a "branch."?   There has to be a better
spot for this variable, and it makes it more future proof, as you
highlighted.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help