[PATCH] builtin-branch: highlight current remote branches with an asterisk

Teach git branch -{r,a} how to interpret remote HEADs and highlight the
corresponding remote branch with an asterisk, instead of showing literal
"<remote_name>/HEAD".

Signed-off-by: Jay Soffian <redacted>
---
git branch -r before patch:
  origin/HEAD
  origin/html
  origin/maint
  origin/man
  origin/master
  origin/next
  origin/pu
  origin/todo

git branch -r after patch:
  origin/html
  origin/maint
  origin/man
* origin/master
  origin/next
  origin/pu
  origin/todo

The coloring for the current remote branch remains red, not green like
the current local branch.

I think it's an improvement. :)

 builtin-branch.c |   41 ++++++++++++++++++++++++++++++-----------
 1 files changed, 30 insertions(+), 11 deletions(-)

diff --git a/builtin-branch.c b/builtin-branch.c
index 56a1971..62558a7 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c

@@ -15,6 +15,7 @@
 #include "branch.h"
 #include "diff.h"
 #include "revision.h"
+#include "string-list.h"
 
 static const char * const builtin_branch_usage[] = {
 	"git branch [options] [-r | -a] [--merged | --no-merged]",

@@ -190,9 +191,19 @@ struct ref_list {
 	int index, alloc, maxwidth;
 	struct ref_item *list;
 	struct commit_list *with_commit;
+	struct string_list *remote_heads;
 	int kinds;
 };
 
+static void add_to_remote_heads(struct string_list *remote_heads, const char *head) {
+	unsigned char sha1[20];
+	int flag;
+	const char *refname = resolve_ref(head, sha1, 0, &flag);
+	if (refname && (flag & REF_ISSYMREF) &&
+	    !prefixcmp(refname, "refs/remotes/"))
+		string_list_insert(refname + 13, remote_heads);
+}
+
 static int append_ref(const char *refname, const unsigned char *sha1, int flags, void *cb_data)
 {
 	struct ref_list *ref_list = (struct ref_list*)(cb_data);

@@ -223,6 +234,13 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
 	if ((kind & ref_list->kinds) == 0)
 		return 0;
 
+	/* Handle remote HEAD */
+	if (kind == REF_REMOTE_BRANCH && ((len = strlen(refname)) > 5) &&
+	    !strcmp(refname + len - 5, "/HEAD")) {
+		add_to_remote_heads(ref_list->remote_heads, refname - 13);
+		return 0;
+	}
+
 	if (merge_filter != NO_FILTER)
 		add_pending_object(&ref_list->revs,
 				   (struct object *)commit, refname);

@@ -294,8 +312,8 @@ static int matches_merge_filter(struct commit *commit)
 static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
 			   int abbrev, int current)
 {
-	char c;
-	int color;
+	char c = ' ';
+	int color = COLOR_BRANCH_PLAIN, current_color = COLOR_BRANCH_CURRENT;
 	struct commit *commit = item->commit;
 
 	if (!matches_merge_filter(commit))

@@ -306,17 +324,13 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
 		color = COLOR_BRANCH_LOCAL;
 		break;
 	case REF_REMOTE_BRANCH:
-		color = COLOR_BRANCH_REMOTE;
-		break;
-	default:
-		color = COLOR_BRANCH_PLAIN;
+		color = current_color = COLOR_BRANCH_REMOTE;
 		break;
 	}
 
-	c = ' ';
 	if (current) {
 		c = '*';
-		color = COLOR_BRANCH_CURRENT;
+		color = current_color;
 	}
 
 	if (verbose) {

@@ -364,10 +378,12 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev, str
 	int i;
 	struct ref_list ref_list;
 	struct commit *head_commit = lookup_commit_reference_gently(head_sha1, 1);
+	struct string_list remote_heads = { NULL, 0, 0, 1};
 
 	memset(&ref_list, 0, sizeof(ref_list));
 	ref_list.kinds = kinds;
 	ref_list.with_commit = with_commit;
+	ref_list.remote_heads = &remote_heads;
 	if (merge_filter != NO_FILTER)
 		init_revisions(&ref_list.revs, NULL);
 	for_each_ref(append_ref, &ref_list);

@@ -399,13 +415,16 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev, str
 	}
 
 	for (i = 0; i < ref_list.index; i++) {
-		int current = !detached &&
+		int current = (!detached &&
 			(ref_list.list[i].kind == REF_LOCAL_BRANCH) &&
-			!strcmp(ref_list.list[i].name, head);
+			!strcmp(ref_list.list[i].name, head)) ||
+			(ref_list.list[i].kind == REF_REMOTE_BRANCH &&
+			string_list_has_string(&remote_heads,
+			                       ref_list.list[i].name));
 		print_ref_item(&ref_list.list[i], ref_list.maxwidth, verbose,
 			       abbrev, current);
 	}
-
+	string_list_clear(&remote_heads, 0);
 	free_ref_list(&ref_list);
 }
 

-- 
1.6.1.2.354.ge44a2

Hi,

On Mon, 9 Feb 2009, Jay Soffian wrote:

Teach git branch -{r,a} how to interpret remote HEADs and highlight the
corresponding remote branch with an asterisk, instead of showing literal
"<remote_name>/HEAD".

Let's hope that nobody's scripts rely on a single star in front of the 
local HEAD...

Ciao,
Dscho

Hi,

Johannes Schindelin [off-list ref] wrote:

Let's hope that nobody's scripts rely on a single star in front of the 
local HEAD...

I don't know if I have any scripts that rely on a single star in front of
the local HEAD or not (I'm sure some people must have them), but I do
think this new feature would be very confusing, especially when used
with -a.

At the very least, make the indicator something other than a star, an @
or #, perhaps.

Cheers,

Mark

On Mon, Feb 9, 2009 at 6:49 PM, Johannes Schindelin
[off-list ref] wrote:

Hi,

On Mon, 9 Feb 2009, Jay Soffian wrote:

quoted

Teach git branch -{r,a} how to interpret remote HEADs and highlight the
corresponding remote branch with an asterisk, instead of showing literal
"<remote_name>/HEAD".

Let's hope that nobody's scripts rely on a single star in front of the
local HEAD...

Perhaps you'd be happier with a different marker for the remote head,
but in any case, git branch is a porcelain, isn't it?

j.

(Please don't trim cc:)

On Mon, Feb 9, 2009 at 7:03 PM, Mark Burton [off-list ref] wrote:

I don't know if I have any scripts that rely on a single star in front of
the local HEAD or not (I'm sure some people must have them), but I do
think this new feature would be very confusing, especially when used
with -a.

At the very least, make the indicator something other than a star, an @
or #, perhaps.

With color, it shouldn't be confusing at all as only one branch is in
green. W/o color, it still seems clear to me as the remote branches
have their remote name prefixed to them. Even if you're on a detached
head:

* (no branch)
  master
  next
  sent/branch-show-remote-HEAD
  wip/am-usability-improvements
  wip/push-docs
  origin/html
  origin/maint
  origin/man
* origin/master
  origin/next
  origin/pu
  origin/todo

A different marker doesn't really seem like an improvement to me:

* (no branch)
  master
  next
  sent/branch-show-remote-HEAD
  wip/am-usability-improvements
  wip/push-docs
  origin/html
  origin/maint
  origin/man
@ origin/master
  origin/next
  origin/pu
  origin/todo

But I'm happy to have the community paint the shed I've constructed.

j.

On 2009.02.09 18:32:06 -0500, Jay Soffian wrote:

Teach git branch -{r,a} how to interpret remote HEADs and highlight the
corresponding remote branch with an asterisk, instead of showing literal
"<remote_name>/HEAD".

Hm, what's the use case for having such a marker? And since only "git
clone" sets up origin/HEAD, while "git remote add foo git://..." won't
create foo/HEAD, you would get that marker for origin only. Also, the
origin/HEAD symref isn't updated, so it doesn't tell you which branch
is "active" in the remote repository now, but which one was active when
you cloned the repo.

So basically, what that marker would tell you is that you can use
"origin" as a short-shortname for the remote tracking branch that has
the marker. I don't see how that is very useful.

If the <name>/HEAD symref would be created for all remotes and would get
updated, that would at least make the marker more meaningful, but I
still don't really see what I'd use it for. From what I've heard, some
people just consider origin/HEAD a clone artifact without much use, and
so far, I think I agree. But maybe there's more to it?

Björn

2009/2/10 Björn Steinbrink [off-list ref]:

On 2009.02.09 18:32:06 -0500, Jay Soffian wrote:

quoted

Teach git branch -{r,a} how to interpret remote HEADs and highlight the
corresponding remote branch with an asterisk, instead of showing literal
"<remote_name>/HEAD".

Hm, what's the use case for having such a marker? And since only "git
clone" sets up origin/HEAD, while "git remote add foo git://..." won't
create foo/HEAD,

git remote add -f ... would create it.

you would get that marker for origin only. Also, the
origin/HEAD symref isn't updated, so it doesn't tell you which branch
is "active" in the remote repository now, but which one was active when
you cloned the repo.

Maybe there should be a way to update it afterwards.

Santi

On 2009.02.10 09:02:02 +0100, Santi Béjar wrote:

2009/2/10 Björn Steinbrink [off-list ref]:

quoted

On 2009.02.09 18:32:06 -0500, Jay Soffian wrote:

quoted

Teach git branch -{r,a} how to interpret remote HEADs and highlight the
corresponding remote branch with an asterisk, instead of showing literal
"<remote_name>/HEAD".

Hm, what's the use case for having such a marker? And since only "git
clone" sets up origin/HEAD, while "git remote add foo git://..." won't
create foo/HEAD,

git remote add -f ... would create it.

No, it won't. Only "git remote add -m <name> ..." would. And there, you
have to pass a branchname yourself, "-m HEAD" doesn't do the trick. So
there you'd have a "the branch I have selected" instead of "the branch
the remote HEAD referenced". Making it quite different from what "git
clone" does.

But actually, that looks like a bug. The docs for -m say that it should
just override what <name>/HEAD is set to, not that it should be required
to cause the <name>/HEAD creation. I'll try to look into that.

quoted

you would get that marker for origin only. Also, the
origin/HEAD symref isn't updated, so it doesn't tell you which branch
is "active" in the remote repository now, but which one was active when
you cloned the repo.

Maybe there should be a way to update it afterwards.

That may not be the default for remotes added with -m though, as
otherwise the -m option to "git remote add" would become quite
pointless.

Björn

On Mon, 9 Feb 2009 19:22:50 -0500
Jay Soffian [off-list ref] wrote:

(Please don't trim cc:)

On Mon, Feb 9, 2009 at 7:03 PM, Mark Burton [off-list ref] wrote:

quoted

I don't know if I have any scripts that rely on a single star in front of
the local HEAD or not (I'm sure some people must have them), but I do
think this new feature would be very confusing, especially when used
with -a.

At the very least, make the indicator something other than a star, an @
or #, perhaps.

With color, it shouldn't be confusing at all as only one branch is in
green. 

How about the colour blind git users?

W/o color, it still seems clear to me as the remote branches
have their remote name prefixed to them. Even if you're on a detached
head:

* (no branch)
  master
  next
  sent/branch-show-remote-HEAD
  wip/am-usability-improvements
  wip/push-docs
  origin/html
  origin/maint
  origin/man
* origin/master
  origin/next
  origin/pu
  origin/todo

A different marker doesn't really seem like an improvement to me:

* (no branch)
  master
  next
  sent/branch-show-remote-HEAD
  wip/am-usability-improvements
  wip/push-docs
  origin/html
  origin/maint
  origin/man
@ origin/master
  origin/next
  origin/pu
  origin/todo

But I'm happy to have the community paint the shed I've constructed.

j.

You can paint a rickety old shed any colour you wish but it doesn't
make it any stronger.

Personally, I think the -> syntax is a much better idea as it is unlikely
to be confused with the existing marker and it shows the relationship
between the (remote) HEAD and remote current branch.

Cheers,

Mark

[let me answer your email in reverse order, which will hopefully make
more sense when reading]

On Tue, Feb 10, 2009 at 08:52:14AM +0100, Björn Steinbrink wrote:

still don't really see what I'd use it for. From what I've heard, some
people just consider origin/HEAD a clone artifact without much use, and
so far, I think I agree. But maybe there's more to it?

The ref "origin" will resolve to "refs/remotes/origin/HEAD", if it
exists. So you can use it as a shorthand for "origin/master" (or
whatever branch is most interesting to you on the remote).

If the <name>/HEAD symref would be created for all remotes and would get
updated, that would at least make the marker more meaningful, but I

It has been noted in the past that it should _not_ be automatically
updated, since it is really about "what is the user's preference for the
'most interesting' branch in this remote". And we don't want to
overwrite some preference that they specified.

So I think it makes sense to:

  - if it doesn't exist, set it up based on the remote's HEAD. Clone
    already does this, but "git remote add -f" should probably do it,
    too. I'm not sure if every fetch should do it.

  - give the user some nice interface (probably via "git remote") to
    move the pointer around (right now, it is "git symbolic-ref
    refs/remotes/$remote/HEAD refs/remotes/$remote/$branch").

  - give the user some nice interface to re-fetch the remote HEAD and
    update refs/remotes/$remote/HEAD with it. Probably as an option to
    the "git remote" invocation above.

-Peff

On 2009.02.10 06:19:07 -0500, Jeff King wrote:

On Tue, Feb 10, 2009 at 08:52:14AM +0100, Björn Steinbrink wrote:

quoted

still don't really see what I'd use it for. From what I've heard, some
people just consider origin/HEAD a clone artifact without much use, and
so far, I think I agree. But maybe there's more to it?

The ref "origin" will resolve to "refs/remotes/origin/HEAD", if it
exists. So you can use it as a shorthand for "origin/master" (or
whatever branch is most interesting to you on the remote).

Yeah, that's what I meant when I said "short-shortname". Maybe it's just
me, but I really can't see myself using that. Would be likely that
"origin" references something else than what I expect, especially when
switching from one repo to another. And doing "git branch -r" to find
out if "origin" is the right thing is slower than just typing the full
shortname right away. Well, just my 2 cents.

quoted

If the <name>/HEAD symref would be created for all remotes and would get
updated, that would at least make the marker more meaningful, but I

It has been noted in the past that it should _not_ be automatically
updated, since it is really about "what is the user's preference for the
'most interesting' branch in this remote". And we don't want to
overwrite some preference that they specified.

Yeah, as I said in the other mail, having it as a default would make add
-m quite pointless.

So I think it makes sense to:

  - if it doesn't exist, set it up based on the remote's HEAD. Clone
    already does this, but "git remote add -f" should probably do it,
    too. I'm not sure if every fetch should do it.

FWIW, I would hate fetch for doing that. I dislike the whole
<remote>/HEAD thing, and wouldn't want fetch to recreate that for me all
the time.

  - give the user some nice interface (probably via "git remote") to
    move the pointer around (right now, it is "git symbolic-ref
    refs/remotes/$remote/HEAD refs/remotes/$remote/$branch").

Maybe "git remote set-master"? Though I kinda dislike the "master" part
of the name, which I just took from the -m option to "remote add",
though. I guess that could increase the confusion about the "master"
branch as pre-setup by "git init" being special, and might lead to
interesting conclusions about that command affecting the remote
repository.

  - give the user some nice interface to re-fetch the remote HEAD and
    update refs/remotes/$remote/HEAD with it. Probably as an option to
    the "git remote" invocation above.

Yeah, would make sense.

Björn

On Tue, Feb 10, 2009 at 12:50:36PM +0100, Björn Steinbrink wrote:

Yeah, that's what I meant when I said "short-shortname". Maybe it's just
me, but I really can't see myself using that. Would be likely that
"origin" references something else than what I expect, especially when
switching from one repo to another. And doing "git branch -r" to find
out if "origin" is the right thing is slower than just typing the full
shortname right away. Well, just my 2 cents.

Hmm. I use it all the time. :) I find it especially useful in one
project where everybody has a personal repo with one interesting branch,
and I am the integration manager. I use "git remote update' to fetch
from everybody, and then I can diff and pull against them just by naming
their remote.

So I think it is just one of those features that some people find useful
and others don't.

Yeah, as I said in the other mail, having it as a default would make add
-m quite pointless.

Not necessarily. You might be interested in some other branch that isn't
their HEAD. So yes, you would hopefully be using it much less because we
would be guessing what you wanted to put there instead of making you
type it. But it would still be useful as an override.

quoted

  - if it doesn't exist, set it up based on the remote's HEAD. Clone
    already does this, but "git remote add -f" should probably do it,
    too. I'm not sure if every fetch should do it.

FWIW, I would hate fetch for doing that. I dislike the whole
<remote>/HEAD thing, and wouldn't want fetch to recreate that for me all
the time.

Yeah, I think that is a good reason not to have fetch do it.

quoted

  - give the user some nice interface (probably via "git remote") to
    move the pointer around (right now, it is "git symbolic-ref
    refs/remotes/$remote/HEAD refs/remotes/$remote/$branch").

Maybe "git remote set-master"? Though I kinda dislike the "master" part
of the name, which I just took from the -m option to "remote add",
though. I guess that could increase the confusion about the "master"
branch as pre-setup by "git init" being special, and might lead to
interesting conclusions about that command affecting the remote
repository.

I think somebody suggested "set-default" in another thread, which
doesn't quite work either. Perhaps "set-head" is too literal? Maybe
"favorite-branch"? :)

-Peff

On 2009.02.10 06:59:43 -0500, Jeff King wrote:

On Tue, Feb 10, 2009 at 12:50:36PM +0100, Björn Steinbrink wrote:

quoted

Yeah, as I said in the other mail, having it as a default would make add
-m quite pointless.

Not necessarily. You might be interested in some other branch that isn't
their HEAD. So yes, you would hopefully be using it much less because we
would be guessing what you wanted to put there instead of making you
type it. But it would still be useful as an override.

I guess you read that in the wrong context (or I replied in the wrong
context). What I meant is that it would be bad if "git remote update" or
"git fetch <remote>" or whatever would update <remote>/HEAD
automatically, as that would kill what you have setup with -m.

Using -m as an override for the automatic guessing makes sense, sure.
It's even what the docs say how it's supposed to work already (it just
doesn't create <remote>/HEAD at all atm, unless -m is given).

Björn

On Tue, Feb 10, 2009 at 01:23:41PM +0100, Björn Steinbrink wrote:

quoted

quoted

Yeah, as I said in the other mail, having it as a default would make add
-m quite pointless.

Not necessarily. You might be interested in some other branch that isn't
their HEAD. So yes, you would hopefully be using it much less because we
would be guessing what you wanted to put there instead of making you
type it. But it would still be useful as an override.

I guess you read that in the wrong context (or I replied in the wrong
context). What I meant is that it would be bad if "git remote update" or
"git fetch <remote>" or whatever would update <remote>/HEAD
automatically, as that would kill what you have setup with -m.

Ah, OK, I totally misunderstood. Yes, I think we are in agreement, then.

-Peff