* [PATCH v2] branch: colour upstream branches
@ 2013-04-14 23:38 Felipe Contreras
2013-04-15 0:47 ` Jeff King
0 siblings, 1 reply; 4+ messages in thread
From: Felipe Contreras @ 2013-04-14 23:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Thomas Rast, Duy Nguyen, Felipe Contreras
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(-)
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
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH v2] branch: colour upstream branches
2013-04-14 23:38 [PATCH v2] branch: colour upstream branches Felipe Contreras
@ 2013-04-15 0:47 ` Jeff King
2013-04-15 1:52 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Jeff King @ 2013-04-15 0:47 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Thomas Rast, Duy Nguyen
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.
-Peff
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] branch: colour upstream branches
2013-04-15 0:47 ` Jeff King
@ 2013-04-15 1:52 ` Junio C Hamano
2013-04-15 2:27 ` Felipe Contreras
0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2013-04-15 1:52 UTC (permalink / raw)
To: Jeff King; +Cc: Felipe Contreras, git, Thomas Rast, Duy Nguyen
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] branch: colour upstream branches
2013-04-15 1:52 ` Junio C Hamano
@ 2013-04-15 2:27 ` Felipe Contreras
0 siblings, 0 replies; 4+ messages in thread
From: Felipe Contreras @ 2013-04-15 2:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Thomas Rast, Duy Nguyen
On Sun, Apr 14, 2013 at 8:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-04-15 2:27 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-14 23:38 [PATCH v2] branch: colour upstream branches Felipe Contreras
2013-04-15 0:47 ` Jeff King
2013-04-15 1:52 ` Junio C Hamano
2013-04-15 2:27 ` Felipe Contreras
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).