* [PATCH 2/4] Rename remote_only to display_mode
[not found] <bec6ab7849e3fcacac23cca44a0ba93282af5fca.1162465753.git.andyparkins@gmail.com>
@ 2006-11-02 11:11 ` Andy Parkins
2006-11-03 2:40 ` Junio C Hamano
2006-11-02 11:11 ` [PATCH 3/4] Default to displaying /all/ non-tag refs, not just locals Andy Parkins
2006-11-02 11:11 ` [PATCH 4/4] Show the branch type after the branch name for remotes Andy Parkins
2 siblings, 1 reply; 38+ messages in thread
From: Andy Parkins @ 2006-11-02 11:11 UTC (permalink / raw)
To: git
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-branch.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 368b68e..85b7007 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -100,12 +100,12 @@ static int ref_cmp(const void *r1, const
return strcmp(*(char **)r1, *(char **)r2);
}
-static void print_ref_list(int remote_only)
+static void print_ref_list(int display_mode)
{
int i;
char c;
- if (remote_only)
+ if (display_mode)
for_each_remote_ref(append_ref, NULL);
else
for_each_branch_ref(append_ref, NULL);
@@ -160,7 +160,7 @@ static void create_branch(const char *na
int cmd_branch(int argc, const char **argv, const char *prefix)
{
- int delete = 0, force_delete = 0, force_create = 0, remote_only = 0;
+ int delete = 0, force_delete = 0, force_create = 0, display_mode = 0;
int reflog = 0;
int i;
@@ -189,7 +189,7 @@ int cmd_branch(int argc, const char **ar
continue;
}
if (!strcmp(arg, "-r")) {
- remote_only = 1;
+ display_mode = 1;
continue;
}
if (!strcmp(arg, "-l")) {
@@ -209,7 +209,7 @@ int cmd_branch(int argc, const char **ar
if (delete)
delete_branches(argc - i, argv + i, force_delete);
else if (i == argc)
- print_ref_list(remote_only);
+ print_ref_list(display_mode);
else if (i == argc - 1)
create_branch(argv[i], head, force_create, reflog);
else if (i == argc - 2)
--
1.4.3.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [PATCH 2/4] Rename remote_only to display_mode
2006-11-02 11:11 ` [PATCH 2/4] Rename remote_only to display_mode Andy Parkins
@ 2006-11-03 2:40 ` Junio C Hamano
2006-11-03 8:40 ` Andy Parkins
2006-11-03 10:52 ` [PATCH] Add support to git-branch to show local and remote branches Andy Parkins
0 siblings, 2 replies; 38+ messages in thread
From: Junio C Hamano @ 2006-11-03 2:40 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> -static void print_ref_list(int remote_only)
> +static void print_ref_list(int display_mode)
> {
> int i;
> char c;
>
> - if (remote_only)
> + if (display_mode)
> for_each_remote_ref(append_ref, NULL);
> else
> for_each_branch_ref(append_ref, NULL);
If you make this a "mode", it probably is better to make 1 and 0
into symbolic constants. This patch taken alone is regression
in readability.
By the way, it might make sense to make it bitfields; that would
allow you to show either one kind or both.
Something like this untested patch, that is...
diff --git a/builtin-branch.c b/builtin-branch.c
index 368b68e..182648c 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -79,45 +79,73 @@ static void delete_branches(int argc, co
}
}
+#define REF_LOCAL_BRANCH 01
+#define REF_REMOTE_BRANCH 02
+
static int ref_index, ref_alloc;
-static char **ref_list;
+static struct ref_list {
+ int kind;
+ char name[FLEX_ARRAY];
+} **ref_list;
-static int append_ref(const char *refname, const unsigned char *sha1, int flags,
- void *cb_data)
+static int append_ref(const char *refname, const unsigned char *sha1,
+ int flags, void *cb_data)
{
+ int kinds = *((int*)cb_data);
+ int this_kind, strip;
+ struct ref_list *elem;
+
+ if (!strncmp(refname, "refs/heads/", 11)) {
+ this_kind = REF_LOCAL_BRANCH;
+ strip = 11;
+ }
+ else if (!strncmp(refname, "refs/remotes/", 13)) {
+ this_kind = REF_REMOTE_BRANCH;
+ strip = 13;
+ }
+ else
+ this_kind = 0;
+
+ if ((this_kind & kinds) == 0)
+ return 0;
+
if (ref_index >= ref_alloc) {
ref_alloc = alloc_nr(ref_alloc);
ref_list = xrealloc(ref_list, ref_alloc * sizeof(char *));
}
-
- ref_list[ref_index++] = xstrdup(refname);
+
+ elem = xcalloc(1, sizeof(*elem) + strlen(refname) - strip);
+ strcpy(elem->name, refname + strip);
+ elem->kind = this_kind;
+ ref_list[ref_index++] = elem;
return 0;
}
-static int ref_cmp(const void *r1, const void *r2)
+static int ref_cmp(const void *r1_, const void *r2_)
{
- return strcmp(*(char **)r1, *(char **)r2);
+ const struct ref_list *r1 = *((const struct ref_list **)r1_);
+ const struct ref_list *r2 = *((const struct ref_list **)r2_);
+
+ if (r1->kind != r2->kind)
+ return r1->kind - r2->kind;
+ return strcmp(r1->name, r2->name);
}
-static void print_ref_list(int remote_only)
+static void print_ref_list(int kinds)
{
int i;
char c;
- if (remote_only)
- for_each_remote_ref(append_ref, NULL);
- else
- for_each_branch_ref(append_ref, NULL);
-
+ for_each_ref(append_ref, &kinds);
qsort(ref_list, ref_index, sizeof(char *), ref_cmp);
for (i = 0; i < ref_index; i++) {
c = ' ';
- if (!strcmp(ref_list[i], head))
+ if (ref_list[i]->kind == REF_LOCAL_BRANCH &&
+ !strcmp(ref_list[i]->name, head))
c = '*';
-
- printf("%c %s\n", c, ref_list[i]);
+ printf("%c %s\n", c, ref_list[i]->name);
}
}
@@ -160,8 +188,9 @@ static void create_branch(const char *na
int cmd_branch(int argc, const char **argv, const char *prefix)
{
- int delete = 0, force_delete = 0, force_create = 0, remote_only = 0;
+ int delete = 0, force_delete = 0, force_create = 0;
int reflog = 0;
+ int kinds = REF_LOCAL_BRANCH;
int i;
git_config(git_default_config);
@@ -189,7 +218,11 @@ int cmd_branch(int argc, const char **ar
continue;
}
if (!strcmp(arg, "-r")) {
- remote_only = 1;
+ kinds = REF_REMOTE_BRANCH;
+ continue;
+ }
+ if (!strcmp(arg, "-a")) {
+ kinds = REF_REMOTE_BRANCH | REF_LOCAL_BRANCH;
continue;
}
if (!strcmp(arg, "-l")) {
@@ -209,7 +242,7 @@ int cmd_branch(int argc, const char **ar
if (delete)
delete_branches(argc - i, argv + i, force_delete);
else if (i == argc)
- print_ref_list(remote_only);
+ print_ref_list(kinds);
else if (i == argc - 1)
create_branch(argv[i], head, force_create, reflog);
else if (i == argc - 2)
^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [PATCH 2/4] Rename remote_only to display_mode
2006-11-03 2:40 ` Junio C Hamano
@ 2006-11-03 8:40 ` Andy Parkins
2006-11-03 10:51 ` Andreas Ericsson
2006-11-03 10:52 ` [PATCH] Add support to git-branch to show local and remote branches Andy Parkins
1 sibling, 1 reply; 38+ messages in thread
From: Andy Parkins @ 2006-11-03 8:40 UTC (permalink / raw)
To: git
On Friday 2006 November 03 02:40, Junio C Hamano wrote:
> If you make this a "mode", it probably is better to make 1 and 0
> into symbolic constants. This patch taken alone is regression
> in readability.
In my own code I would have done exactly that; however I've been trying to
keep my patches as minimal as possible.
Digressing a little: what is the polite form of patches for git? My strategy
with this set was to make each patch as small as possible to reach my end
point. If those patches were okayed on the list, I could then do a "make
more beautiful" patch, which is really nothing to do with the original
changes to functionality but would make the code prettier. Really I'm asking
what level of intrusiveness of patch is not considered rude? In making my
patches, should I ride rough-shod over current implementation and just do it
how I'd do it or should I try to fit in (as I did in this case)?
> Something like this untested patch, that is...
I'm very much in favour; I shall make changes of this form soon.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 2/4] Rename remote_only to display_mode
2006-11-03 8:40 ` Andy Parkins
@ 2006-11-03 10:51 ` Andreas Ericsson
2006-11-03 11:51 ` Junio C Hamano
2006-11-03 12:00 ` Andy Parkins
0 siblings, 2 replies; 38+ messages in thread
From: Andreas Ericsson @ 2006-11-03 10:51 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins wrote:
> Digressing a little: what is the polite form of patches for git? My strategy
> with this set was to make each patch as small as possible to reach my end
> point. If those patches were okayed on the list, I could then do a "make
> more beautiful" patch, which is really nothing to do with the original
> changes to functionality but would make the code prettier.
I believe the order of preferrence goes: tested, concise, short.
Linus has a nasty habit of ending his mails with "totally untested
ofcourse", which is not a good strategy to adopt if you want your
patches included.
> Really I'm asking
> what level of intrusiveness of patch is not considered rude? In making my
> patches, should I ride rough-shod over current implementation and just do it
> how I'd do it or should I try to fit in (as I did in this case)?
>
If you *need* to change something, change it. If you *want* to change
something just because it's not written the way you would write it, back
away. If you think some interface you're using needs clearing up
(codewise or with extra comments), send a separate patch for that so the
actual feature/bugfix you're sending in doesn't drown in cosmetic
changes to the interfaces the patch uses/touches.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 2/4] Rename remote_only to display_mode
2006-11-03 10:51 ` Andreas Ericsson
@ 2006-11-03 11:51 ` Junio C Hamano
2006-11-03 12:37 ` Andy Parkins
2006-11-03 12:00 ` Andy Parkins
1 sibling, 1 reply; 38+ messages in thread
From: Junio C Hamano @ 2006-11-03 11:51 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Andreas Ericsson
Andreas Ericsson <ae@op5.se> writes:
> Andy Parkins wrote:
>> Digressing a little: what is the polite form of patches for git? My
>> strategy with this set was to make each patch as small as possible
>> to reach my end point. If those patches were okayed on the list, I
>> could then do a "make more beautiful" patch, which is really nothing
>> to do with the original changes to functionality but would make the
>> code prettier.
>
> I believe the order of preferrence goes: tested, concise, short.
>
> Linus has a nasty habit of ending his mails with "totally untested
> ofcourse", which is not a good strategy to adopt if you want your
> patches included.
I've picked it up as well. Consider it a privilege for being
the toplevel maintainer ;-).
Seriously, it is perfectly Ok to send "for discussion" feelers
that are untested or messy, but marking them clearly as "for
discussion only -- will clean-up after discussion" would be very
much appreciated.
The organization of our four series was almost perfect, except
you went a bit too far with [2/4]. I said "taken alone this is
regression in readability", with the full knowledge that the
real reason of the change was that it would not make any sense
to call the variable "remote_only" in [3/4]. IOW, I would have
rolled 2 and 3 into a single change.
> If you *need* to change something, change it. If you *want* to change
> something just because it's not written the way you would write it,
> back away. If you think some interface you're using needs clearing up
> (codewise or with extra comments), send a separate patch for that so
> the actual feature/bugfix you're sending in doesn't drown in cosmetic
> changes to the interfaces the patch uses/touches.
This is a very good advice. I fully agree with Andreas.
When I was an active contributor, somebody (I do not remember
who) asked me privately: "you seem to be getting along pretty
well with Linus; I have these changes I want to send in, but can
you suggest a good strategy to get patches accepted?" I recall
saying something along this line:
- Make sure the patches apply cleanly to upstream (rebase if
necessary).
- When making a series, make clean-ups and obviously correct
ones early, then follow them with bigger and potentially more
controversial ones. Doing it the other way around takes the
"obviously correct" ones hostage to the latter; IOW, you
would be effectively saying "if you swallow this big change,
you would get these clean-ups and obviously correct
bugfixes", which is not nice to the maintainer.
- When some of your changes are accepted but others were not,
do not give up, if you believe in the cause, try to come up
with convincing examples to explain why your change helps
certain workflows.
- When doing so, make sure the patches apply cleanly to the
updated upstream that now has some of your changes. It might
have been applied with fix-ups, and other people may have
made clean-ups in neighbouring area. You may need to re-roll
the patch.
- Linus is not doing this full-time and is a busy person.
Although "not giving up" is important, do not push him too
hard. Try to guess how busy he is and what area his
attention currently is. The latter is important for two
reasons. (1) If you have to touch the same part of code but
for a different reason, that would add more work on him. It
is better wait until the upstream code settles in the part of
the code and base your patch on that. (2) If your change
needs a deep thinking to swallow, it is likely to be dropped
when Linus's attention is in completely different area.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 2/4] Rename remote_only to display_mode
2006-11-03 11:51 ` Junio C Hamano
@ 2006-11-03 12:37 ` Andy Parkins
0 siblings, 0 replies; 38+ messages in thread
From: Andy Parkins @ 2006-11-03 12:37 UTC (permalink / raw)
To: git
On Friday 2006 November 03 11:51, Junio C Hamano wrote:
> Seriously, it is perfectly Ok to send "for discussion" feelers
Thank you for all the excellent advice. Being new here I'm basically trying
not to make a nuisance of myself :-)
I'll worry less about getting these things right first time; no one here goes
mad if a patch is wrong and I'm quite enjoying myself really :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 2/4] Rename remote_only to display_mode
2006-11-03 10:51 ` Andreas Ericsson
2006-11-03 11:51 ` Junio C Hamano
@ 2006-11-03 12:00 ` Andy Parkins
2006-11-03 13:23 ` Andreas Ericsson
1 sibling, 1 reply; 38+ messages in thread
From: Andy Parkins @ 2006-11-03 12:00 UTC (permalink / raw)
To: git
On Friday 2006 November 03 10:51, Andreas Ericsson wrote:
> If you *need* to change something, change it. If you *want* to change
> something just because it's not written the way you would write it, back
> away. If you think some interface you're using needs clearing up
> (codewise or with extra comments), send a separate patch for that so the
> actual feature/bugfix you're sending in doesn't drown in cosmetic
> changes to the interfaces the patch uses/touches.
Thank you for the excellent advice. What then would you suggest in the case
in point? I made as minimal a change as I could make; but that left the code
a little bit bitty - I had press-ganged a variable into taking on another
function and was using numeric literals that should really have been given
meaning with #define?
My question is perhaps different from simply git-etiquette; it's should I
prefer my patches to be minimal or neat? If there is a more appropriate way
of doing something should I do it or should I favour minimalism?
I've actually rewritten it now as per Junio's request, and while I'm happier
with the code, it was much bigger change, that didn't really lend itself to
being broken into smaller patches as did my first attempt.
I guess in the end it's a judgement call and the best thing to do is post it
and see who shoots it down :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 2/4] Rename remote_only to display_mode
2006-11-03 12:00 ` Andy Parkins
@ 2006-11-03 13:23 ` Andreas Ericsson
0 siblings, 0 replies; 38+ messages in thread
From: Andreas Ericsson @ 2006-11-03 13:23 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins wrote:
> On Friday 2006 November 03 10:51, Andreas Ericsson wrote:
>
>> If you *need* to change something, change it. If you *want* to change
>> something just because it's not written the way you would write it, back
>> away. If you think some interface you're using needs clearing up
>> (codewise or with extra comments), send a separate patch for that so the
>> actual feature/bugfix you're sending in doesn't drown in cosmetic
>> changes to the interfaces the patch uses/touches.
>
> Thank you for the excellent advice. What then would you suggest in the case
> in point? I made as minimal a change as I could make; but that left the code
> a little bit bitty - I had press-ganged a variable into taking on another
> function and was using numeric literals that should really have been given
> meaning with #define?
>
> My question is perhaps different from simply git-etiquette; it's should I
> prefer my patches to be minimal or neat? If there is a more appropriate way
> of doing something should I do it or should I favour minimalism?
>
Neat, imo. Re-using old variables might be appropriate if the name of
the variable still makes sense, but rename it if there's a better name
for it.
> I've actually rewritten it now as per Junio's request, and while I'm happier
> with the code, it was much bigger change, that didn't really lend itself to
> being broken into smaller patches as did my first attempt.
>
> I guess in the end it's a judgement call and the best thing to do is post it
> and see who shoots it down :-)
>
Probably the most sensible approach. Even though the list is pretty
trigger-happy, the guns are more of the playful water-squirt type than
the high-powered big-calibre kind.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] Add support to git-branch to show local and remote branches
2006-11-03 2:40 ` Junio C Hamano
2006-11-03 8:40 ` Andy Parkins
@ 2006-11-03 10:52 ` Andy Parkins
2006-11-03 12:06 ` [PATCH] Colourise git-branch output Andy Parkins
2006-11-03 12:08 ` [PATCH] Add support to git-branch to show local and remote branches Junio C Hamano
1 sibling, 2 replies; 38+ messages in thread
From: Andy Parkins @ 2006-11-03 10:52 UTC (permalink / raw)
To: git
Instead of storing a list of refnames in append_ref, a list of structures is
created. Each of these stores the refname and a symbolic constant representing
its type.
The creation of the list is filtered based on a command line switch; no switch
means "local branches only", "-r" means "remote branches only" (as they always
did); but now "-a" means "local branches or remote branches".
As a side effect, the list is now not global, but allocated in print_ref_list()
where it used.
Also a memory leak is plugged, the memory allocated during the list creation
was never freed. This is now done in the new function, tidy_ref_list()
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-branch.c | 95 +++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 77 insertions(+), 18 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 368b68e..6dd33ee 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -79,46 +79,100 @@ static void delete_branches(int argc, co
}
}
-static int ref_index, ref_alloc;
-static char **ref_list;
+#define REF_UNKNOWN_TYPE 0x00
+#define REF_LOCAL_BRANCH 0x01
+#define REF_REMOTE_BRANCH 0x02
+#define REF_TAG 0x04
+
+struct ref_item {
+ char *name;
+ unsigned int type;
+};
+
+struct ref_list {
+ int index, alloc;
+ struct ref_item *list;
+ int type_wanted;
+};
static int append_ref(const char *refname, const unsigned char *sha1, int flags,
void *cb_data)
{
- if (ref_index >= ref_alloc) {
- ref_alloc = alloc_nr(ref_alloc);
- ref_list = xrealloc(ref_list, ref_alloc * sizeof(char *));
+ struct ref_list *ref_list = (struct ref_list*)(cb_data);
+ struct ref_item *newitem;
+ int type = REF_UNKNOWN_TYPE;
+
+ /* Detect type */
+ if (!strncmp(refname, "refs/heads/", 11)) {
+ type = REF_LOCAL_BRANCH;
+ refname += 11;
+ } else if (!strncmp(refname, "refs/remotes/", 13)) {
+ type = REF_REMOTE_BRANCH;
+ refname += 13;
+ } else if (!strncmp(refname, "refs/tags/", 10)) {
+ type = REF_TAG;
+ refname += 10;
+ }
+
+ /* Don't add type the caller doesn't want */
+ if ((type & ref_list->type_wanted) == 0) {
+ return 0;
+ }
+
+ /* Resize buffer */
+ if (ref_list->index >= ref_list->alloc) {
+ ref_list->alloc = alloc_nr(ref_list->alloc);
+ ref_list->list = xrealloc(ref_list->list,
+ ref_list->alloc * sizeof(struct ref_item));
}
- ref_list[ref_index++] = xstrdup(refname);
+ /* Record the new item */
+ newitem = &(ref_list->list[ref_list->index++]);
+ newitem->name = xstrdup(refname);
+ newitem->type = type;
return 0;
}
+static int tidy_ref_list( struct ref_list *ref_list )
+{
+ int i;
+ for (i = 0; i < ref_list->index; i++) {
+ free( ref_list->list[i].name );
+ }
+ free( ref_list->list );
+}
+
static int ref_cmp(const void *r1, const void *r2)
{
+ struct ref_item *c1 = (struct ref_item*)(r1),
+ *c2 = (struct ref_item*)(r2);
+ if( c1->type != c2->type )
+ return c1->type - c2->type;
return strcmp(*(char **)r1, *(char **)r2);
}
-static void print_ref_list(int remote_only)
+static void print_ref_list( int type_wanted )
{
int i;
char c;
+ struct ref_list ref_list;
- if (remote_only)
- for_each_remote_ref(append_ref, NULL);
- else
- for_each_branch_ref(append_ref, NULL);
+ memset( &ref_list, 0, sizeof( ref_list ) );
+ ref_list.type_wanted = type_wanted;
+ for_each_ref(append_ref, &ref_list);
- qsort(ref_list, ref_index, sizeof(char *), ref_cmp);
+ qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
- for (i = 0; i < ref_index; i++) {
+ for (i = 0; i < ref_list.index; i++) {
c = ' ';
- if (!strcmp(ref_list[i], head))
+ if (!strcmp(ref_list.list[i].name, head))
c = '*';
- printf("%c %s\n", c, ref_list[i]);
+ printf("%c %s\n", c, ref_list.list[i].name);
}
+
+ tidy_ref_list( &ref_list );
}
static void create_branch(const char *name, const char *start,
@@ -160,9 +214,10 @@ static void create_branch(const char *na
int cmd_branch(int argc, const char **argv, const char *prefix)
{
- int delete = 0, force_delete = 0, force_create = 0, remote_only = 0;
+ int delete = 0, force_delete = 0, force_create = 0;
int reflog = 0;
int i;
+ int type_wanted = REF_LOCAL_BRANCH;
git_config(git_default_config);
@@ -189,7 +244,11 @@ int cmd_branch(int argc, const char **ar
continue;
}
if (!strcmp(arg, "-r")) {
- remote_only = 1;
+ type_wanted = REF_REMOTE_BRANCH;
+ continue;
+ }
+ if (!strcmp(arg, "-a")) {
+ type_wanted = REF_LOCAL_BRANCH | REF_REMOTE_BRANCH;
continue;
}
if (!strcmp(arg, "-l")) {
@@ -209,7 +268,7 @@ int cmd_branch(int argc, const char **ar
if (delete)
delete_branches(argc - i, argv + i, force_delete);
else if (i == argc)
- print_ref_list(remote_only);
+ print_ref_list(type_wanted);
else if (i == argc - 1)
create_branch(argv[i], head, force_create, reflog);
else if (i == argc - 2)
--
1.4.3.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH] Colourise git-branch output
2006-11-03 10:52 ` [PATCH] Add support to git-branch to show local and remote branches Andy Parkins
@ 2006-11-03 12:06 ` Andy Parkins
2006-11-03 19:25 ` Junio C Hamano
2006-11-03 12:08 ` [PATCH] Add support to git-branch to show local and remote branches Junio C Hamano
1 sibling, 1 reply; 38+ messages in thread
From: Andy Parkins @ 2006-11-03 12:06 UTC (permalink / raw)
To: git
I wanted to have a visual indication of which branches are local and which are
remote in git-branch -a output; however Junio was concerned that someone might
be using the output in a script. This patch addresses the problem by colouring
the git-branch output - which in "auto" mode won't be activated.
I've based it off the colouring code for builtin-diff.c; which means there is a
branch.color configuration variable that needs setting to something before the
color will appear.
This patch chooses green for local, red for remote and bold green for current.
As yet, there is no support for changing the colors using the config file; but
it wouldn't be hard to add.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-branch.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 54 insertions(+), 3 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 6dd33ee..de7f81e 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -5,6 +5,7 @@
* Based on git-branch.sh by Junio C Hamano.
*/
+#include "color.h"
#include "cache.h"
#include "refs.h"
#include "commit.h"
@@ -17,6 +18,38 @@ static const char builtin_branch_usage[]
static const char *head;
static unsigned char head_sha1[20];
+static int branch_use_color;
+static char branch_colors[][COLOR_MAXLEN] = {
+ "\033[m", /* reset */
+ "", /* PLAIN (normal) */
+ "\033[31m", /* REMOTE (red) */
+ "\033[32m", /* LOCAL (green) */
+ "\033[1;32m", /* CURRENT (boldgreen) */
+};
+enum color_branch {
+ COLOR_BRANCH_RESET = 0,
+ COLOR_BRANCH_PLAIN = 1,
+ COLOR_BRANCH_REMOTE = 2,
+ COLOR_BRANCH_LOCAL = 3,
+ COLOR_BRANCH_CURRENT = 4,
+};
+
+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);
+}
+
+const char *branch_get_color(enum color_branch ix)
+{
+ if (branch_use_color)
+ return branch_colors[ix];
+ return "";
+}
+
static int in_merge_bases(const unsigned char *sha1,
struct commit *rev1,
struct commit *rev2)
@@ -157,6 +190,7 @@ static void print_ref_list( int type_wan
int i;
char c;
struct ref_list ref_list;
+ int color;
memset( &ref_list, 0, sizeof( ref_list ) );
ref_list.type_wanted = type_wanted;
@@ -165,11 +199,28 @@ static void print_ref_list( int type_wan
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
for (i = 0; i < ref_list.index; i++) {
+ switch( ref_list.list[i].type ) {
+ case REF_LOCAL_BRANCH:
+ color = COLOR_BRANCH_LOCAL;
+ break;
+ case REF_REMOTE_BRANCH:
+ color = COLOR_BRANCH_REMOTE;
+ break;
+ default:
+ color = COLOR_BRANCH_PLAIN;
+ break;
+ }
+
c = ' ';
- if (!strcmp(ref_list.list[i].name, head))
+ if (!strcmp(ref_list.list[i].name, head)) {
c = '*';
+ color = COLOR_BRANCH_CURRENT;
+ }
- printf("%c %s\n", c, ref_list.list[i].name);
+ printf("%c %s%s%s\n", c,
+ branch_get_color(color),
+ ref_list.list[i].name,
+ branch_get_color(COLOR_BRANCH_RESET));
}
tidy_ref_list( &ref_list );
@@ -219,7 +270,7 @@ int cmd_branch(int argc, const char **ar
int i;
int type_wanted = REF_LOCAL_BRANCH;
- git_config(git_default_config);
+ git_config(git_branch_config);
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
--
1.4.3.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-11-03 12:06 ` [PATCH] Colourise git-branch output Andy Parkins
@ 2006-11-03 19:25 ` Junio C Hamano
2006-11-03 23:05 ` Alex Riesen
0 siblings, 1 reply; 38+ messages in thread
From: Junio C Hamano @ 2006-11-03 19:25 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> I wanted to have a visual indication of which branches are
> local and which are remote in git-branch -a output; however
> Junio was concerned that someone might be using the output in
> a script. This patch addresses the problem by colouring the
> git-branch output - which in "auto" mode won't be activated.
Yuck. We are getting more and more color happy. As long as
this stays optional I'm Ok with it; we'll see if people find it
useful soon enough.
> @@ -165,11 +199,28 @@ static void print_ref_list( int type_wan
> qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
>
> for (i = 0; i < ref_list.index; i++) {
> + switch( ref_list.list[i].type ) {
> + case REF_LOCAL_BRANCH:
> + color = COLOR_BRANCH_LOCAL;
> + break;
Style. SP between "switch" and open parenthesis, no SP after
that open parenthesis. We tend to align "switch", "case", and
"default" on the same column.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-11-03 19:25 ` Junio C Hamano
@ 2006-11-03 23:05 ` Alex Riesen
0 siblings, 0 replies; 38+ messages in thread
From: Alex Riesen @ 2006-11-03 23:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
Junio C Hamano, Fri, Nov 03, 2006 20:25:59 +0100:
> > I wanted to have a visual indication of which branches are
> > local and which are remote in git-branch -a output; however
> > Junio was concerned that someone might be using the output in
> > a script. This patch addresses the problem by colouring the
> > git-branch output - which in "auto" mode won't be activated.
>
> Yuck. We are getting more and more color happy. As long as
> this stays optional I'm Ok with it; we'll see if people find it
> useful soon enough.
>
As long as the output stays stable one can always colorize it with
an external program, using pseudo terminals, if needed. Wont work
for the other platform though. As usual.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Add support to git-branch to show local and remote branches
2006-11-03 10:52 ` [PATCH] Add support to git-branch to show local and remote branches Andy Parkins
2006-11-03 12:06 ` [PATCH] Colourise git-branch output Andy Parkins
@ 2006-11-03 12:08 ` Junio C Hamano
2006-11-03 12:40 ` Andy Parkins
1 sibling, 1 reply; 38+ messages in thread
From: Junio C Hamano @ 2006-11-03 12:08 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> Instead of storing a list of refnames in append_ref, a list of
> structures is created. Each of these stores the refname and a
> symbolic constant representing its type.
>
> The creation of the list is filtered based on a command line
> switch; no switch means "local branches only", "-r" means
> "remote branches only" (as they always did); but now "-a"
> means "local branches or remote branches".
>
> As a side effect, the list is now not global, but allocated in
> print_ref_list() where it used.
>
> Also a memory leak is plugged, the memory allocated during the
> list creation was never freed. This is now done in the new
> function, tidy_ref_list()
I would not call that a "leak" given that print_ref_list() is
the last thing to be called before the command exits. I'd
rather not to spend cycles calling free().
> +static int tidy_ref_list( struct ref_list *ref_list )
Style. No spaces before or after parameter list.
I see you already parse "refs/tags" prefix. "git branch" would
not print tags, but that part might be useful when we want to
redo git-tag in C.
Other than that, I think it is equivalent to what I have in "pu"
right now.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Add support to git-branch to show local and remote branches
2006-11-03 12:08 ` [PATCH] Add support to git-branch to show local and remote branches Junio C Hamano
@ 2006-11-03 12:40 ` Andy Parkins
2006-11-03 19:19 ` Junio C Hamano
0 siblings, 1 reply; 38+ messages in thread
From: Andy Parkins @ 2006-11-03 12:40 UTC (permalink / raw)
To: git
On Friday 2006 November 03 12:08, Junio C Hamano wrote:
> > +static int tidy_ref_list( struct ref_list *ref_list )
>
> Style. No spaces before or after parameter list.
Bah! It's so hard getting my fingers to remember what style goes in which
project :-)
> I see you already parse "refs/tags" prefix. "git branch" would
> not print tags, but that part might be useful when we want to
> redo git-tag in C.
I'm going to have a look at that soon; I've got enough of a hang of things
with this git-branch work that I think I could cope with writing git-tag in
C.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Add support to git-branch to show local and remote branches
2006-11-03 12:40 ` Andy Parkins
@ 2006-11-03 19:19 ` Junio C Hamano
0 siblings, 0 replies; 38+ messages in thread
From: Junio C Hamano @ 2006-11-03 19:19 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> On Friday 2006 November 03 12:08, Junio C Hamano wrote:
>
>> > +static int tidy_ref_list( struct ref_list *ref_list )
>>
>> Style. No spaces before or after parameter list.
>
> Bah! It's so hard getting my fingers to remember what style goes in which
> project :-)
>
>> I see you already parse "refs/tags" prefix. "git branch" would
>> not print tags, but that part might be useful when we want to
>> redo git-tag in C.
>
> I'm going to have a look at that soon;...
Just to make sure you do not misunderstand. I do not see much
need for rewriting git-tag in C right now, and often it is more
convenient to leave higher layer commands in shell scripts to
allow people to try out new things and flush out UI issues. I
was merely pointing out that part of the code would be usable if
we were to do it.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 3/4] Default to displaying /all/ non-tag refs, not just locals
[not found] <bec6ab7849e3fcacac23cca44a0ba93282af5fca.1162465753.git.andyparkins@gmail.com>
2006-11-02 11:11 ` [PATCH 2/4] Rename remote_only to display_mode Andy Parkins
@ 2006-11-02 11:11 ` Andy Parkins
2006-11-03 2:40 ` Junio C Hamano
2006-11-02 11:11 ` [PATCH 4/4] Show the branch type after the branch name for remotes Andy Parkins
2 siblings, 1 reply; 38+ messages in thread
From: Andy Parkins @ 2006-11-02 11:11 UTC (permalink / raw)
To: git
Adds support for display_mode == 2; which shows all non-tag refs. I've set
display_mode = 2 by default so it's easily reverted if needed - or if a switch
for the old mode is wanted it can be easily added
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-branch.c | 32 +++++++++++++++++++++++++-------
1 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 85b7007..b88413a 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -104,20 +104,38 @@ static void print_ref_list(int display_m
{
int i;
char c;
+ char *p;
- if (display_mode)
- for_each_remote_ref(append_ref, NULL);
- else
- for_each_branch_ref(append_ref, NULL);
+ switch (display_mode) {
+ case 0:
+ for_each_branch_ref(append_ref, NULL);
+ break;
+ case 1:
+ for_each_remote_ref(append_ref, NULL);
+ break;
+ case 2:
+ for_each_ref(append_ref, NULL);
+ break;
+ }
qsort(ref_list, ref_index, sizeof(char *), ref_cmp);
for (i = 0; i < ref_index; i++) {
+ p = ref_list[i];
+ if (display_mode == 2) {
+ if (!strncmp( p, "refs/", 5 ))
+ p += 5;
+ if (!strncmp( p, "tags/", 5 ))
+ continue;
+ if (!strncmp( p, "heads/", 6 ))
+ p += 6;
+ }
+
c = ' ';
- if (!strcmp(ref_list[i], head))
+ if (!strcmp(p, head))
c = '*';
- printf("%c %s\n", c, ref_list[i]);
+ printf("%c %s\n", c, p);
}
}
@@ -160,7 +178,7 @@ static void create_branch(const char *na
int cmd_branch(int argc, const char **argv, const char *prefix)
{
- int delete = 0, force_delete = 0, force_create = 0, display_mode = 0;
+ int delete = 0, force_delete = 0, force_create = 0, display_mode = 2;
int reflog = 0;
int i;
--
1.4.3.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [PATCH 3/4] Default to displaying /all/ non-tag refs, not just locals
2006-11-02 11:11 ` [PATCH 3/4] Default to displaying /all/ non-tag refs, not just locals Andy Parkins
@ 2006-11-03 2:40 ` Junio C Hamano
2006-11-03 8:47 ` Andy Parkins
0 siblings, 1 reply; 38+ messages in thread
From: Junio C Hamano @ 2006-11-03 2:40 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> Adds support for display_mode == 2; which shows all non-tag refs.
That is a change in behaviour and given that we introduced
remotes for the explicit purpose of not to clutter the local
branch namespace, I doubt defaulting to _show_ remotes is a good
change. See the 'bitfield' comment in my other reply.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 3/4] Default to displaying /all/ non-tag refs, not just locals
2006-11-03 2:40 ` Junio C Hamano
@ 2006-11-03 8:47 ` Andy Parkins
2006-11-03 10:55 ` Andreas Ericsson
0 siblings, 1 reply; 38+ messages in thread
From: Andy Parkins @ 2006-11-03 8:47 UTC (permalink / raw)
To: git
On Friday 2006 November 03 02:40, Junio C Hamano wrote:
> That is a change in behaviour and given that we introduced
> remotes for the explicit purpose of not to clutter the local
> branch namespace, I doubt defaulting to _show_ remotes is a good
Really? I had imagined it was to prevent accidental checking out of an
upstream-tracking branch. Also; I don't think "not cluttering the namespace"
is the same as "not showing multiple namespaces". The local namespace
remains as uncluttered as it ever was. This is a question of what to
display.
Assuming my "mixed mode" display thing were in place, doesn't that make the
two choices of UI
1)
git-branch : show local branches
git-branch --all : show local and remote branches
git-branch -r : show remote branches
2)
git-branch : show local and remote branches
git-branch --local : show local branches
git-branch -r : show remote branches
In case 2) the switch is simply selecting a filter, and so fits in with
the "-r" better.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 3/4] Default to displaying /all/ non-tag refs, not just locals
2006-11-03 8:47 ` Andy Parkins
@ 2006-11-03 10:55 ` Andreas Ericsson
0 siblings, 0 replies; 38+ messages in thread
From: Andreas Ericsson @ 2006-11-03 10:55 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins wrote:
> On Friday 2006 November 03 02:40, Junio C Hamano wrote:
>
>> That is a change in behaviour and given that we introduced
>> remotes for the explicit purpose of not to clutter the local
>> branch namespace, I doubt defaulting to _show_ remotes is a good
>
> Really? I had imagined it was to prevent accidental checking out of an
> upstream-tracking branch. Also; I don't think "not cluttering the namespace"
> is the same as "not showing multiple namespaces". The local namespace
> remains as uncluttered as it ever was. This is a question of what to
> display.
>
> Assuming my "mixed mode" display thing were in place, doesn't that make the
> two choices of UI
>
> 1)
> git-branch : show local branches
> git-branch --all : show local and remote branches
> git-branch -r : show remote branches
> 2)
> git-branch : show local and remote branches
> git-branch --local : show local branches
> git-branch -r : show remote branches
>
> In case 2) the switch is simply selecting a filter, and so fits in with
> the "-r" better.
>
I think it'd make more sense if git-branch could instead take a --filter
parameter that does a simple strncmp(filter, branch, strlen(filter)) to
see if it should show a branch or not. That way, "--filter=remotes"
would work splendidly. "local" as keyword to "--filter" could possibly
be a special case and need documentation.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 4/4] Show the branch type after the branch name for remotes
[not found] <bec6ab7849e3fcacac23cca44a0ba93282af5fca.1162465753.git.andyparkins@gmail.com>
2006-11-02 11:11 ` [PATCH 2/4] Rename remote_only to display_mode Andy Parkins
2006-11-02 11:11 ` [PATCH 3/4] Default to displaying /all/ non-tag refs, not just locals Andy Parkins
@ 2006-11-02 11:11 ` Andy Parkins
2006-11-03 2:40 ` Junio C Hamano
2 siblings, 1 reply; 38+ messages in thread
From: Andy Parkins @ 2006-11-02 11:11 UTC (permalink / raw)
To: git
Instead of prefixing the remote branches with "remotes/" suffix them with
"[read only]"
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-branch.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index b88413a..6736882 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -105,6 +105,7 @@ static void print_ref_list(int display_m
int i;
char c;
char *p;
+ const char *suffix;
switch (display_mode) {
case 0:
@@ -122,6 +123,7 @@ static void print_ref_list(int display_m
for (i = 0; i < ref_index; i++) {
p = ref_list[i];
+ suffix = "";
if (display_mode == 2) {
if (!strncmp( p, "refs/", 5 ))
p += 5;
@@ -129,13 +131,17 @@ static void print_ref_list(int display_m
continue;
if (!strncmp( p, "heads/", 6 ))
p += 6;
+ if (!strncmp( p, "remotes/", 8 )) {
+ suffix = " [read only]";
+ p += 8;
+ }
}
c = ' ';
if (!strcmp(p, head))
c = '*';
- printf("%c %s\n", c, p);
+ printf("%c %s%s\n", c, p, suffix);
}
}
--
1.4.3.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [PATCH 4/4] Show the branch type after the branch name for remotes
2006-11-02 11:11 ` [PATCH 4/4] Show the branch type after the branch name for remotes Andy Parkins
@ 2006-11-03 2:40 ` Junio C Hamano
2006-11-03 8:33 ` Andy Parkins
0 siblings, 1 reply; 38+ messages in thread
From: Junio C Hamano @ 2006-11-03 2:40 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> Instead of prefixing the remote branches with "remotes/" suffix them with
> "[read only]"
This is a change in UI and while I understand why you want to
say r/o instead of remotes/, I think this needs a bit more
thought and discussion. People should not be feeding the output
of "git branch" Porcelainish to their scripts, but you'll never
know...
By the way, does "git branch -r" (without any of your patches)
even say "remotes/"?
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 4/4] Show the branch type after the branch name for remotes
2006-11-03 2:40 ` Junio C Hamano
@ 2006-11-03 8:33 ` Andy Parkins
2006-11-03 20:08 ` Junio C Hamano
0 siblings, 1 reply; 38+ messages in thread
From: Andy Parkins @ 2006-11-03 8:33 UTC (permalink / raw)
To: git
On Friday 2006 November 03 02:40, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
> > Instead of prefixing the remote branches with "remotes/" suffix them with
> > "[read only]"
>
> This is a change in UI and while I understand why you want to
> say r/o instead of remotes/, I think this needs a bit more
> thought and discussion. People should not be feeding the output
> of "git branch" Porcelainish to their scripts, but you'll never
> know...
I intentionally made this patch in such a way as to leave the original form
available. I haven't added a switch to show the original form, but it's
there if it's needed.
The reason I thought it would be acceptable is that the output changed fairly
significantly when git-branch went builtin.
Here's the original and my "git-branch -r" run on my git repository
$ git-branch -r
remotes/up/maint
remotes/up/master
remotes/up/next
remotes/up/pu
$ ./git-branch -r
momentum/master
up/maint
up/master
up/next
up/pu
I've not touched the "-r" path, so this is the same as the unpatched builtin
branch. The "remotes/" prefix is removed in refs.c by for_each_remote_ref()
with do_for_each_ref("refs/remotes/", fn, 13, cb_data); and the spaces are
added because print_ref_list() has only one printing path and that always
includes spaces.
For me personally, I find my git-branch output more useful because in it's
unswitched form it shows me all branches. However, I can easily put this
behaviour under a switch or, and this would get my vote, put the original
behaviour (i.e. show local branches only) under a switch.
Which would you like? If any.
> By the way, does "git branch -r" (without any of your patches)
> even say "remotes/"?
I haven't touched the "-r" path, so that output should be unaffected. As
mentioned above, git-branch.sh did include "remotes/", new builtin branch
does not, but does include " " at the beginning of every line.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 4/4] Show the branch type after the branch name for remotes
2006-11-03 8:33 ` Andy Parkins
@ 2006-11-03 20:08 ` Junio C Hamano
0 siblings, 0 replies; 38+ messages in thread
From: Junio C Hamano @ 2006-11-03 20:08 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> For me personally, I find my git-branch output more useful because in it's
> unswitched form it shows me all branches. However, I can easily put this
> behaviour under a switch or, and this would get my vote, put the original
> behaviour (i.e. show local branches only) under a switch.
>
> Which would you like? If any.
I am a wrong person to ask, since I do not usually work in
repositories with refs/remotes/ myself and the choice would not
affect me either way.
For people who work with multiple remotes (e.g. following both
Linus and Jeff) and work on many separate topic branches of
their own, I would suspect that showing only local branches by
default, with an option to show remote branches from only named
remotes would make things less cluttered, and we can always have
"-a" to mean everything under the sun.
This kind of limiting can be done more flexibly with globbing
than just fixed set of flags.
We could have:
git branch --list 'heads/'
git branch --list 'remotes/jgarzik/'
git branch --list 'heads/??/*'
and that command, crazily enough, would let you do:
git branch --list 'tags/v2.6.19-rc*'
Hmm?
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] Colourise git-branch output
@ 2006-12-11 22:10 Andy Parkins
2006-12-11 22:47 ` Junio C Hamano
2006-12-12 0:38 ` Sean
0 siblings, 2 replies; 38+ messages in thread
From: Andy Parkins @ 2006-12-11 22:10 UTC (permalink / raw)
To: git
I wanted to have a visual indication of which branches are local and which are
remote in git-branch -a output; however Junio was concerned that someone might
be using the output in a script. This patch addresses the problem by colouring
the git-branch output - which in "auto" mode won't be activated.
I've based it off the colouring code for builtin-diff.c; which means there is a
branch.color configuration variable that needs setting to something before the
color will appear.
This patch chooses green for local, red for remote and bold green for current.
As yet, there is no support for changing the colors using the config file; but
it wouldn't be hard to add.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
I know Junio isn't keen on adding colour all over the place in git; but I
think it's appropriate here. When running in "git-branch -a" mode (or even
"git-branch -r" mode for that matter), because the "refs/remotes" prefix is
stripped from the branch name, there is no way to distinguish between local
and remote branches. Colouring them makes it easy to see which is which,
but more importantly doesn't break any scripts because the colour would be
automatically disabled.
builtin-branch.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 59 insertions(+), 5 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 3d5cb0e..1c1fa8f 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -5,6 +5,7 @@
* Based on git-branch.sh by Junio C Hamano.
*/
+#include "color.h"
#include "cache.h"
#include "refs.h"
#include "commit.h"
@@ -17,6 +18,38 @@ static const char builtin_branch_usage[] =
static const char *head;
static unsigned char head_sha1[20];
+static int branch_use_color;
+static char branch_colors[][COLOR_MAXLEN] = {
+ "\033[m", /* reset */
+ "", /* PLAIN (normal) */
+ "\033[31m", /* REMOTE (red) */
+ "\033[32m", /* LOCAL (green) */
+ "\033[1;32m", /* CURRENT (boldgreen) */
+};
+enum color_branch {
+ COLOR_BRANCH_RESET = 0,
+ COLOR_BRANCH_PLAIN = 1,
+ COLOR_BRANCH_REMOTE = 2,
+ COLOR_BRANCH_LOCAL = 3,
+ COLOR_BRANCH_CURRENT = 4,
+};
+
+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);
+}
+
+const char *branch_get_color(enum color_branch ix)
+{
+ if (branch_use_color)
+ return branch_colors[ix];
+ return "";
+}
+
static int in_merge_bases(const unsigned char *sha1,
struct commit *rev1,
struct commit *rev2)
@@ -183,6 +216,7 @@ static void print_ref_list(int kinds, int verbose, int abbrev)
int i;
char c;
struct ref_list ref_list;
+ int color;
memset(&ref_list, 0, sizeof(ref_list));
ref_list.kinds = kinds;
@@ -191,18 +225,38 @@ static void print_ref_list(int kinds, int verbose, int abbrev)
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
for (i = 0; i < ref_list.index; i++) {
+ switch( ref_list.list[i].kind ) {
+ case REF_LOCAL_BRANCH:
+ color = COLOR_BRANCH_LOCAL;
+ break;
+ case REF_REMOTE_BRANCH:
+ color = COLOR_BRANCH_REMOTE;
+ break;
+ default:
+ color = COLOR_BRANCH_PLAIN;
+ break;
+ }
+
c = ' ';
if (ref_list.list[i].kind == REF_LOCAL_BRANCH &&
- !strcmp(ref_list.list[i].name, head))
+ !strcmp(ref_list.list[i].name, head)) {
c = '*';
+ color = COLOR_BRANCH_CURRENT;
+ }
if (verbose) {
- printf("%c %-*s", c, ref_list.maxwidth,
- ref_list.list[i].name);
+ printf("%c %s%-*s%s", c,
+ branch_get_color(color),
+ ref_list.maxwidth,
+ ref_list.list[i].name,
+ branch_get_color(COLOR_BRANCH_RESET));
print_ref_info(ref_list.list[i].sha1, abbrev);
}
else
- printf("%c %s\n", c, ref_list.list[i].name);
+ printf("%c %s%s%s\n", c,
+ branch_get_color(color),
+ ref_list.list[i].name,
+ branch_get_color(COLOR_BRANCH_RESET));
}
free_ref_list(&ref_list);
@@ -253,7 +307,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
int kinds = REF_LOCAL_BRANCH;
int i;
- git_config(git_default_config);
+ git_config(git_branch_config);
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
--
1.4.4.1.geeee8
^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-12-11 22:10 [PATCH] Colourise git-branch output Andy Parkins
@ 2006-12-11 22:47 ` Junio C Hamano
2006-12-12 0:38 ` Sean
1 sibling, 0 replies; 38+ messages in thread
From: Junio C Hamano @ 2006-12-11 22:47 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> I wanted to have a visual indication of which branches are
> local and which are remote in git-branch -a output; however
> Junio was concerned that someone might be using the output in
> a script. This patch addresses the problem by colouring the
> git-branch output - which in "auto" mode won't be activated.
Hmm.
"git branch --color" does not seem to work, so is this config
only?
> As yet, there is no support for changing the colors using the
> config file; but it wouldn't be hard to add.
I am not sure about that. Would it be something like this?
[branch.color]
remote = purple
local = yellow
I wonder what would happen when you have a branch called
"color". Would the above cause "git-fetch" to fetch from
"purple" remote by default?
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-12-11 22:10 [PATCH] Colourise git-branch output Andy Parkins
2006-12-11 22:47 ` Junio C Hamano
@ 2006-12-12 0:38 ` Sean
2006-12-12 1:11 ` Junio C Hamano
1 sibling, 1 reply; 38+ messages in thread
From: Sean @ 2006-12-12 0:38 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
On Mon, 11 Dec 2006 22:10:08 +0000
Andy Parkins <andyparkins@gmail.com> wrote:
> +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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-12-12 0:38 ` Sean
@ 2006-12-12 1:11 ` Junio C Hamano
2006-12-12 1:24 ` Sean
0 siblings, 1 reply; 38+ messages in thread
From: Junio C Hamano @ 2006-12-12 1:11 UTC (permalink / raw)
To: Sean; +Cc: git
Sean <seanlkml@sympatico.ca> writes:
> On Mon, 11 Dec 2006 22:10:08 +0000
> Andy Parkins <andyparkins@gmail.com> wrote:
>
>> +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".
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-12-12 1:11 ` Junio C Hamano
@ 2006-12-12 1:24 ` Sean
2006-12-12 3:39 ` Linus Torvalds
0 siblings, 1 reply; 38+ messages in thread
From: Sean @ 2006-12-12 1:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Mon, 11 Dec 2006 17:11:24 -0800
Junio C Hamano <junkio@cox.net> wrote:
> > 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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-12-12 1:24 ` Sean
@ 2006-12-12 3:39 ` Linus Torvalds
2006-12-12 5:07 ` Junio C Hamano
0 siblings, 1 reply; 38+ messages in thread
From: Linus Torvalds @ 2006-12-12 3:39 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, git
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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-12-12 3:39 ` Linus Torvalds
@ 2006-12-12 5:07 ` Junio C Hamano
2006-12-12 5:41 ` Linus Torvalds
0 siblings, 1 reply; 38+ messages in thread
From: Junio C Hamano @ 2006-12-12 5:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sean, git
Linus Torvalds <torvalds@osdl.org> writes:
> 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.
I tend to agree. We probably should start deprecating
diff.color and diff.color.<stuff> and swap them around,
like this:
[color]
diff = auto
branch = auto
# it begs "* = auto" entry perhaps...
[color.diff]
old = red
new = green
[color.branch]
remote = purple
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-12-12 5:07 ` Junio C Hamano
@ 2006-12-12 5:41 ` Linus Torvalds
2006-12-12 7:58 ` Junio C Hamano
0 siblings, 1 reply; 38+ messages in thread
From: Linus Torvalds @ 2006-12-12 5:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, git
On Mon, 11 Dec 2006, Junio C Hamano wrote:
>
> [color]
> diff = auto
> branch = auto
> # it begs "* = auto" entry perhaps...
> [color.diff]
> old = red
> new = green
> [color.branch]
> remote = purple
I wish you'd learn to use the proper syntax ;)
It would be
[color "diff"]
old = red
new = green
and what's nice about it is that you can also do
[color "diff"]
auto
old = red
new = green
and the config file rules for booleans are such that a config variable
without the "= val" part parses the same as "= true", so you can now do
git repo-config --bool color.diff.auto
and it will say "true".
Now, I just think that would be a nice syntax.
Of course, for legacy reasons, and for people who rather than keeping the
_color_ information together want to keep the _diff_ information together,
we can/probably-should support both color.diff.* and diff.color.* formats.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-12-12 5:41 ` Linus Torvalds
@ 2006-12-12 7:58 ` Junio C Hamano
0 siblings, 0 replies; 38+ messages in thread
From: Junio C Hamano @ 2006-12-12 7:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Linus Torvalds <torvalds@osdl.org> writes:
> I wish you'd learn to use the proper syntax ;)
Ok, ok, I'm an old timer. But [color.diff] syntax is also
accepted and I have it in my ~/.gitconfig:
$ cat ~/.gitconfig
[diff.color]
old = red reverse
$ git repo-config --global diff.color.old
red reverse
$ exit
> ... what's nice about it is that you can also do
>
> [color "diff"]
> auto
> old = red
> new = green
>
> and the config file rules for booleans are such that a config variable
> without the "= val" part parses the same as "= true", so you can now do
>
> git repo-config --bool color.diff.auto
>
> and it will say "true".
I find that your version of "auto" above to be utterly
confusing.
The existing configuration variable diff.color as an extended
boolean takes true, false or "auto".
I do agree this is a nice way to say that I pretend to be color
blind to git repo-config:
$ git repo-config --global --bool color.diff false
$ cat ~/.gitconfig
[color]
diff = false
and it is also nice to be able to say my preference is "auto"
with (you can have --bool with this example and still use
"auto", by the way, when setting):
$ git repo-config --global color.diff auto
$ cat ~/.gitconfig
[color]
diff = auto
I also agree it is nice that the "boolean magic" kicks in when
we hand-craft it:
$ cat ~/.gitconfig
[color]
diff
$ git repo-config --global --bool color.diff
true
But your handcrafted
[color "diff"]
auto
simply feels a very confusing syntax. How would you even
express my preference is always-color (that is, "true")?
If we are changing color.diff to color.diff.usecolor which is
bool + auto, then I would understand it.
[color "diff"]
usecolor
# usecolor = auto
# usecolor = no
but that would not let you query with --bool ("auto" would
barf).
I guess we should at least extend --bool so that scripts can
easily query extended bools; if the value looks like a bool (or
there is no value), it would return it normalized to "true" or
"false" so they do not have to say:
case `repo-config --bool the.variable` in
true | yes | on | 1)
echo ah you mean yes ;;
esac
but if the value is not either boolean true or false, then
return the string as is (such as "auto"). I am inclined to just
extend --bool itself to do so (which means we would lose the
error checking form the script for truly boolean fields) rather
than adding a new --bool-or-string option.
In any case,
[color]
diff
# diff = auto
# diff = no
would work already if we only talk about built-in accesses. We
would need to extend repo-config --bool to make it easier for
scripts to work with this extended bool, but that is a minor
detail.
So it seems to me that the only reason to have
color.diff.usecolor is so that we can have "diff" related color
settings in one place. Which is fine.
You could do the same thing with your "auto"
[color "diff"]
auto
# auto = always
# auto = no
but what that means is that color.diff.auto _is_ the extended
boolean that tells us to:
* use color on terminal when set to true
* use color unconditionally when set to a non-bool 'always'
* never use color when set to false
which sounds rather, eh, unusual.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH] Colourise git-branch output
@ 2006-12-12 6:41 Andy Parkins
2006-12-12 8:46 ` Johannes Sixt
2006-12-12 18:43 ` Junio C Hamano
0 siblings, 2 replies; 38+ messages in thread
From: Andy Parkins @ 2006-12-12 6:41 UTC (permalink / raw)
To: git
I wanted to have a visual indication of which branches are local and
which are remote in git-branch -a output; however Junio was concerned
that someone might be using the output in a script. This patch
addresses the problem by colouring the git-branch output - which in
"auto" mode won't be activated.
I've based it off the colouring code for builtin-diff.c; which means
there is a branch color configuration variable that needs setting to
something before the color will appear.
The colour parameter is "color.branch" rather than "branch.color" to
avoid clashing with the default namespace for default branch merge
definitions.
This patch chooses green for local, red for remote and bold green for
current.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-branch.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 87 insertions(+), 5 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 3d5cb0e..7c87b8d 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -5,6 +5,7 @@
* Based on git-branch.sh by Junio C Hamano.
*/
+#include "color.h"
#include "cache.h"
#include "refs.h"
#include "commit.h"
@@ -17,6 +18,58 @@ static const char builtin_branch_usage[] =
static const char *head;
static unsigned char head_sha1[20];
+static int branch_use_color;
+static char branch_colors[][COLOR_MAXLEN] = {
+ "\033[m", /* reset */
+ "", /* PLAIN (normal) */
+ "\033[31m", /* REMOTE (red) */
+ "\033[32m", /* LOCAL (green) */
+ "\033[1;32m", /* CURRENT (boldgreen) */
+};
+enum color_branch {
+ COLOR_BRANCH_RESET = 0,
+ COLOR_BRANCH_PLAIN = 1,
+ COLOR_BRANCH_REMOTE = 2,
+ COLOR_BRANCH_LOCAL = 3,
+ COLOR_BRANCH_CURRENT = 4,
+};
+
+static int parse_branch_color_slot(const char *var, int ofs)
+{
+ if (!strcasecmp(var+ofs, "plain"))
+ return COLOR_BRANCH_PLAIN;
+ if (!strcasecmp(var+ofs, "reset"))
+ return COLOR_BRANCH_RESET;
+ if (!strcasecmp(var+ofs, "remote"))
+ return COLOR_BRANCH_REMOTE;
+ if (!strcasecmp(var+ofs, "local"))
+ return COLOR_BRANCH_LOCAL;
+ if (!strcasecmp(var+ofs, "current"))
+ return COLOR_BRANCH_CURRENT;
+ die("bad config variable '%s'", var);
+}
+
+int git_branch_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "color.branch")) {
+ branch_use_color = git_config_colorbool(var, value);
+ return 0;
+ }
+ if (!strncmp(var, "color.branch.", 13)) {
+ int slot = parse_branch_color_slot(var, 13);
+ color_parse(value, var, branch_colors[slot]);
+ return 0;
+ }
+ return git_default_config(var, value);
+}
+
+const char *branch_get_color(enum color_branch ix)
+{
+ if (branch_use_color)
+ return branch_colors[ix];
+ return "";
+}
+
static int in_merge_bases(const unsigned char *sha1,
struct commit *rev1,
struct commit *rev2)
@@ -183,6 +236,7 @@ static void print_ref_list(int kinds, int verbose, int abbrev)
int i;
char c;
struct ref_list ref_list;
+ int color;
memset(&ref_list, 0, sizeof(ref_list));
ref_list.kinds = kinds;
@@ -191,18 +245,38 @@ static void print_ref_list(int kinds, int verbose, int abbrev)
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
for (i = 0; i < ref_list.index; i++) {
+ switch( ref_list.list[i].kind ) {
+ case REF_LOCAL_BRANCH:
+ color = COLOR_BRANCH_LOCAL;
+ break;
+ case REF_REMOTE_BRANCH:
+ color = COLOR_BRANCH_REMOTE;
+ break;
+ default:
+ color = COLOR_BRANCH_PLAIN;
+ break;
+ }
+
c = ' ';
if (ref_list.list[i].kind == REF_LOCAL_BRANCH &&
- !strcmp(ref_list.list[i].name, head))
+ !strcmp(ref_list.list[i].name, head)) {
c = '*';
+ color = COLOR_BRANCH_CURRENT;
+ }
if (verbose) {
- printf("%c %-*s", c, ref_list.maxwidth,
- ref_list.list[i].name);
+ printf("%c %s%-*s%s", c,
+ branch_get_color(color),
+ ref_list.maxwidth,
+ ref_list.list[i].name,
+ branch_get_color(COLOR_BRANCH_RESET));
print_ref_info(ref_list.list[i].sha1, abbrev);
}
else
- printf("%c %s\n", c, ref_list.list[i].name);
+ printf("%c %s%s%s\n", c,
+ branch_get_color(color),
+ ref_list.list[i].name,
+ branch_get_color(COLOR_BRANCH_RESET));
}
free_ref_list(&ref_list);
@@ -253,7 +327,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
int kinds = REF_LOCAL_BRANCH;
int i;
- git_config(git_default_config);
+ git_config(git_branch_config);
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
@@ -297,6 +371,14 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
verbose = 1;
continue;
}
+ if (!strcmp(arg, "--color")) {
+ branch_use_color = 1;
+ continue;
+ }
+ if (!strcmp(arg, "--no-color")) {
+ branch_use_color = 0;
+ continue;
+ }
usage(builtin_branch_usage);
}
--
1.4.4.1.geeee8
^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-12-12 6:41 Andy Parkins
@ 2006-12-12 8:46 ` Johannes Sixt
2006-12-12 10:10 ` Junio C Hamano
2006-12-12 18:43 ` Junio C Hamano
1 sibling, 1 reply; 38+ messages in thread
From: Johannes Sixt @ 2006-12-12 8:46 UTC (permalink / raw)
To: git
Andy Parkins wrote:
> This patch chooses green for local, red for remote and bold green for
> current.
Sorry for chiming in so late, but red and green are usually poor choices
since red-green color-blindness is surprisingly frequent...
Maybe its sufficient to have just the remote branches (dark-)red, and
the rest in the default color, with the current branch bold?
-- Hannes
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-12-12 8:46 ` Johannes Sixt
@ 2006-12-12 10:10 ` Junio C Hamano
2006-12-12 11:03 ` Andy Parkins
0 siblings, 1 reply; 38+ messages in thread
From: Junio C Hamano @ 2006-12-12 10:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Andy Parkins
Johannes Sixt <J.Sixt@eudaptics.com> writes:
> Andy Parkins wrote:
>> This patch chooses green for local, red for remote and bold green for
>> current.
>
> Sorry for chiming in so late, but red and green are usually poor choices
> since red-green color-blindness is surprisingly frequent...
>
> Maybe its sufficient to have just the remote branches (dark-)red, and
> the rest in the default color, with the current branch bold?
Even without red-green blindness issue, I think that makes
sense. colored-diff uses green/red for added/deleted but that
is shown against the context in plain. A sane thing to do for
branch listing would be to show the usual case (i.e. local) in
plain and show the remote ones differently.
Something like this on top of Andy's?
If we keep '*' prefix for the current one, I do not see a reason
to show it in a different color from other local branches, by
the way, but I did not go that far in this patch.
---
diff --git a/builtin-branch.c b/builtin-branch.c
index 7c87b8d..d1c243d 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -23,8 +23,8 @@ static char branch_colors[][COLOR_MAXLEN] = {
"\033[m", /* reset */
"", /* PLAIN (normal) */
"\033[31m", /* REMOTE (red) */
- "\033[32m", /* LOCAL (green) */
- "\033[1;32m", /* CURRENT (boldgreen) */
+ "", /* LOCAL (normal) */
+ "\033[32m", /* CURRENT (green) */
};
enum color_branch {
COLOR_BRANCH_RESET = 0,
^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-12-12 10:10 ` Junio C Hamano
@ 2006-12-12 11:03 ` Andy Parkins
2006-12-12 18:43 ` Junio C Hamano
0 siblings, 1 reply; 38+ messages in thread
From: Andy Parkins @ 2006-12-12 11:03 UTC (permalink / raw)
To: git
On Tuesday 2006 December 12 10:10, Junio C Hamano wrote:
> Even without red-green blindness issue, I think that makes
> sense. colored-diff uses green/red for added/deleted but that
I certainly don't have any objection. For me, the use of colour is not to
make things look pretty it's to give visual queues.
> is shown against the context in plain. A sane thing to do for
> branch listing would be to show the usual case (i.e. local) in
> plain and show the remote ones differently.
The only reason I picked red and green was to indicate "can be checked out"
and "cannot be checked out". However, when git eventually allows arbitrary
commits to be checked out that green/red, can/can't distinction will be
meaningless anyway.
> + "", /* LOCAL (normal) */
> + "\033[32m", /* CURRENT (green) */
In keeping with the "don't use green" idea - can I suggest just bold normal
for the CURRENT? That way there is the most minimal use of colour for the
default git-branch output, but still retaining a visual indicator.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-12-12 11:03 ` Andy Parkins
@ 2006-12-12 18:43 ` Junio C Hamano
0 siblings, 0 replies; 38+ messages in thread
From: Junio C Hamano @ 2006-12-12 18:43 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
>> + "", /* LOCAL (normal) */
>> + "\033[32m", /* CURRENT (green) */
>
> In keeping with the "don't use green" idea - can I suggest just bold normal
> for the CURRENT? That way there is the most minimal use of colour for the
> default git-branch output, but still retaining a visual indicator.
I do not have strong preference either way.
The CURRENT is highlighted with '*' so I think we certainly can
lose green and even go vanilla. I only tried to avoid bold
because no built-in default coloring currently use it, and in
the past I've worked with terminals that do not have enough
contrast between normal and bold and for some people that might
become an issue.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH] Colourise git-branch output
2006-12-12 6:41 Andy Parkins
2006-12-12 8:46 ` Johannes Sixt
@ 2006-12-12 18:43 ` Junio C Hamano
1 sibling, 0 replies; 38+ messages in thread
From: Junio C Hamano @ 2006-12-12 18:43 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> The colour parameter is "color.branch" rather than "branch.color" to
> avoid clashing with the default namespace for default branch merge
> definitions.
Very nice.
> c = ' ';
> if (ref_list.list[i].kind == REF_LOCAL_BRANCH &&
> - !strcmp(ref_list.list[i].name, head))
> + !strcmp(ref_list.list[i].name, head)) {
> c = '*';
> + color = COLOR_BRANCH_CURRENT;
> + }
>
> if (verbose) {
> - printf("%c %-*s", c, ref_list.maxwidth,
> - ref_list.list[i].name);
> + printf("%c %s%-*s%s", c,
> + branch_get_color(color),
> + ref_list.maxwidth,
> + ref_list.list[i].name,
> + branch_get_color(COLOR_BRANCH_RESET));
> print_ref_info(ref_list.list[i].sha1, abbrev);
> }
> else
> - printf("%c %s\n", c, ref_list.list[i].name);
> + printf("%c %s%s%s\n", c,
> + branch_get_color(color),
> + ref_list.list[i].name,
> + branch_get_color(COLOR_BRANCH_RESET));
> }
Now this makes me wonder if under output coloring we would still
want the two-space indent and '*' prefix.
^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2006-12-12 18:43 UTC | newest]
Thread overview: 38+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <bec6ab7849e3fcacac23cca44a0ba93282af5fca.1162465753.git.andyparkins@gmail.com>
2006-11-02 11:11 ` [PATCH 2/4] Rename remote_only to display_mode Andy Parkins
2006-11-03 2:40 ` Junio C Hamano
2006-11-03 8:40 ` Andy Parkins
2006-11-03 10:51 ` Andreas Ericsson
2006-11-03 11:51 ` Junio C Hamano
2006-11-03 12:37 ` Andy Parkins
2006-11-03 12:00 ` Andy Parkins
2006-11-03 13:23 ` Andreas Ericsson
2006-11-03 10:52 ` [PATCH] Add support to git-branch to show local and remote branches Andy Parkins
2006-11-03 12:06 ` [PATCH] Colourise git-branch output Andy Parkins
2006-11-03 19:25 ` Junio C Hamano
2006-11-03 23:05 ` Alex Riesen
2006-11-03 12:08 ` [PATCH] Add support to git-branch to show local and remote branches Junio C Hamano
2006-11-03 12:40 ` Andy Parkins
2006-11-03 19:19 ` Junio C Hamano
2006-11-02 11:11 ` [PATCH 3/4] Default to displaying /all/ non-tag refs, not just locals Andy Parkins
2006-11-03 2:40 ` Junio C Hamano
2006-11-03 8:47 ` Andy Parkins
2006-11-03 10:55 ` Andreas Ericsson
2006-11-02 11:11 ` [PATCH 4/4] Show the branch type after the branch name for remotes Andy Parkins
2006-11-03 2:40 ` Junio C Hamano
2006-11-03 8:33 ` Andy Parkins
2006-11-03 20:08 ` Junio C Hamano
2006-12-11 22:10 [PATCH] Colourise git-branch output Andy Parkins
2006-12-11 22:47 ` Junio C Hamano
2006-12-12 0:38 ` Sean
2006-12-12 1:11 ` Junio C Hamano
2006-12-12 1:24 ` Sean
2006-12-12 3:39 ` Linus Torvalds
2006-12-12 5:07 ` Junio C Hamano
2006-12-12 5:41 ` Linus Torvalds
2006-12-12 7:58 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2006-12-12 6:41 Andy Parkins
2006-12-12 8:46 ` Johannes Sixt
2006-12-12 10:10 ` Junio C Hamano
2006-12-12 11:03 ` Andy Parkins
2006-12-12 18:43 ` Junio C Hamano
2006-12-12 18:43 ` Junio C Hamano
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).