threads / patch / 33512

v2branch: colour upstream branches

Subject: [PATCH v2] branch: colour upstream branches

## tl;dr

4 messages between Apr 14, 2013 and Apr 15, 2013. Diffs are folded; open one to read it.

replies: 3people: 3as markdown or json

Felipe Contreras· Apr 14, 2013, 23:38 UTC · lore

Otherwise when using 'git branch -vv' it's hard to see them among so much output.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Documentation/config.txt |  3 ++-
 builtin/branch.c         | 35 +++++++++++++++++++++++++++--------
 2 files changed, 29 insertions(+), 9 deletions(-)
Show changes to 2 files +29 −9

Documentation/config.txt, builtin/branch.c

diff --git a/Documentation/config.txt b/Documentation/config.txt
index bc750d5..302533f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -794,7 +794,8 @@ color.branch::
 color.branch.<slot>::
 	Use customized color for branch coloration. `<slot>` is one of
 	`current` (the current branch), `local` (a local branch),
-	`remote` (a remote-tracking branch in refs/remotes/), `plain` (other
+	`remote` (a remote-tracking branch in refs/remotes/),
+	`upstream` (upstream tracking branch), `plain` (other
 	refs).
 +
 The value for these configuration variables is a list of colors (at most
diff --git a/builtin/branch.c b/builtin/branch.c
index 00d17d2..9696419 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -40,13 +40,15 @@ static char branch_colors[][COLOR_MAXLEN] = {
 	GIT_COLOR_RED,		/* REMOTE */
 	GIT_COLOR_NORMAL,	/* LOCAL */
 	GIT_COLOR_GREEN,	/* CURRENT */
+	GIT_COLOR_BLUE,		/* UPSTREAM */
 };
 enum color_branch {
 	BRANCH_COLOR_RESET = 0,
 	BRANCH_COLOR_PLAIN = 1,
 	BRANCH_COLOR_REMOTE = 2,
 	BRANCH_COLOR_LOCAL = 3,
-	BRANCH_COLOR_CURRENT = 4
+	BRANCH_COLOR_CURRENT = 4,
+	BRANCH_COLOR_UPSTREAM = 5,
 };
 
 static enum merge_filter {
@@ -71,6 +73,8 @@ static int parse_branch_color_slot(const char *var, int ofs)
 		return BRANCH_COLOR_LOCAL;
 	if (!strcasecmp(var+ofs, "current"))
 		return BRANCH_COLOR_CURRENT;
+	if (!strcasecmp(var+ofs, "upstream"))
+		return BRANCH_COLOR_UPSTREAM;
 	return -1;
 }
 
@@ -417,32 +421,47 @@ static void fill_tracking_info(struct strbuf *stat, const char *branch_name,
 	int ours, theirs;
 	char *ref = NULL;
 	struct branch *branch = branch_get(branch_name);
+	char fancy[80];
 
 	if (!stat_tracking_info(branch, &ours, &theirs)) {
 		if (branch && branch->merge && branch->merge[0]->dst &&
-		    show_upstream_ref)
-			strbuf_addf(stat, "[%s] ",
-			    shorten_unambiguous_ref(branch->merge[0]->dst, 0));
+		    show_upstream_ref) {
+			ref = shorten_unambiguous_ref(branch->merge[0]->dst, 0);
+			if (want_color(branch_use_color))
+				strbuf_addf(stat, "[%s%s%s] ",
+						branch_get_color(BRANCH_COLOR_UPSTREAM),
+						ref, branch_get_color(BRANCH_COLOR_RESET));
+			else
+				strbuf_addf(stat, "[%s] ", ref);
+		}
 		return;
 	}
 
-	if (show_upstream_ref)
+	if (show_upstream_ref) {
 		ref = shorten_unambiguous_ref(branch->merge[0]->dst, 0);
+		if (want_color(branch_use_color))
+			snprintf(fancy, sizeof(fancy), "%s%s%s",
+					branch_get_color(BRANCH_COLOR_UPSTREAM),
+					ref, branch_get_color(BRANCH_COLOR_RESET));
+		else
+			strncpy(fancy, ref, sizeof(fancy));
+	}
+
 	if (!ours) {
 		if (ref)
-			strbuf_addf(stat, _("[%s: behind %d]"), ref, theirs);
+			strbuf_addf(stat, _("[%s: behind %d]"), fancy, theirs);
 		else
 			strbuf_addf(stat, _("[behind %d]"), theirs);
 
 	} else if (!theirs) {
 		if (ref)
-			strbuf_addf(stat, _("[%s: ahead %d]"), ref, ours);
+			strbuf_addf(stat, _("[%s: ahead %d]"), fancy, ours);
 		else
 			strbuf_addf(stat, _("[ahead %d]"), ours);
 	} else {
 		if (ref)
 			strbuf_addf(stat, _("[%s: ahead %d, behind %d]"),
-				    ref, ours, theirs);
+				    fancy, ours, theirs);
 		else
 			strbuf_addf(stat, _("[ahead %d, behind %d]"),
 				    ours, theirs);

-- 
1.8.2.1.643.ge3cc75d
Jeff King· Apr 15, 2013, 00:47 UTC · re: Felipe Contreras · lore

Re: [PATCH v2] branch: colour upstream branches

On Sun, Apr 14, 2013 at 06:38:27PM -0500, Felipe Contreras wrote:
Show 6 quoted lines
> +		if (want_color(branch_use_color))
> +			snprintf(fancy, sizeof(fancy), "%s%s%s",
> +					branch_get_color(BRANCH_COLOR_UPSTREAM),
> +					ref, branch_get_color(BRANCH_COLOR_RESET));
> +		else
> +			strncpy(fancy, ref, sizeof(fancy));
  $ man strncpy | grep -C1 Warning
  The strncpy() function is similar, except that at most n bytes of src are
  copied.  Warning: If there is no null byte among the first n bytes of src,
  the string placed in dest will not be null-terminated.
-Peff
Junio C Hamano· Apr 15, 2013, 01:52 UTC · re: Jeff King · lore

Re: [PATCH v2] branch: colour upstream branches

Jeff King <peff@peff.net> writes:
Show 13 quoted lines
> On Sun, Apr 14, 2013 at 06:38:27PM -0500, Felipe Contreras wrote:
>
>> +		if (want_color(branch_use_color))
>> +			snprintf(fancy, sizeof(fancy), "%s%s%s",
>> +					branch_get_color(BRANCH_COLOR_UPSTREAM),
>> +					ref, branch_get_color(BRANCH_COLOR_RESET));
>> +		else
>> +			strncpy(fancy, ref, sizeof(fancy));
>
>   $ man strncpy | grep -C1 Warning
>   The strncpy() function is similar, except that at most n bytes of src are
>   copied.  Warning: If there is no null byte among the first n bytes of src,
>   the string placed in dest will not be null-terminated.

Is there a reason to avoid strbuf_addf() here? We are talking about output for human consumption and not performance critical code, no?

Felipe Contreras· Apr 15, 2013, 02:27 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] branch: colour upstream branches

On Sun, Apr 14, 2013 at 8:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 18 quoted lines
> Jeff King <peff@peff.net> writes:
>
>> On Sun, Apr 14, 2013 at 06:38:27PM -0500, Felipe Contreras wrote:
>>
>>> +            if (want_color(branch_use_color))
>>> +                    snprintf(fancy, sizeof(fancy), "%s%s%s",
>>> +                                    branch_get_color(BRANCH_COLOR_UPSTREAM),
>>> +                                    ref, branch_get_color(BRANCH_COLOR_RESET));
>>> +            else
>>> +                    strncpy(fancy, ref, sizeof(fancy));
>>
>>   $ man strncpy | grep -C1 Warning
>>   The strncpy() function is similar, except that at most n bytes of src are
>>   copied.  Warning: If there is no null byte among the first n bytes of src,
>>   the string placed in dest will not be null-terminated.
>
> Is there a reason to avoid strbuf_addf() here?  We are talking about
> output for human consumption and not performance critical code, no?

It's not about the performance, it's about the amount of code. But I already agreed to do this.

-- 
Felipe Contreras

← back to recent threads