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 <jaysoffian@gmail.com>
---
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 && ...
[ message continues ]

Hi,


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

Ciao,
Dscho
--

[ message continues ]

Hi,


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
--

[ message continues ]

(Please don't trim cc:)


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.
--

[ message continues ]

On Mon, 9 Feb 2009 19:22:50 -0500


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
--

[ message continues ]

People use "git branch | sed -ne 's/^\* //p' in their scripts (you can say
"against recommendation" but I think it is a sign that the recommendation
against use of Porcelain in the scripts is not loud enough).  I do not
think anybody greps in "git branch -a", though, for that purpose.

The current "branch -a" output is a mess.  It omits "remotes/" even though
it includes the local ones in the output.  Perhaps with remotes/, the
output may become a bit more readable:

    $ git branch -a
    * master
      next
      pu
    * remotes/dscho/master
    * remotes/origin/master
      remotes/origin/next
      remotes/origin/pu
    * remotes/spearce/master

which may still be too loud with asterisks, but at least there is no
confusion.  Or perhaps like this:

    $ git branch -a
    * master
      next
      pu
      remotes/dscho/HEAD -> master
      remotes/dscho/master
      remotes/origin/HEAD -> master
      remotes/origin/master
      remotes/origin/next
      remotes/origin/pu
      remotes/spearce/HEAD -> master
      remotes/spearce/master

with an obvious twist when there is no mixed output:

    $ git branch -r
      dscho/HEAD -> master
      dscho/master
      origin/HEAD -> master
      origin/master
      origin/next
      origin/pu
      spearce/HEAD -> master
      spearce/master
--

[ message continues ]

For me it makes sense.

Also this type of output for symrefs "-> master" makes even more sense
in the verbose output.

Santi
--

[ message continues ]

On Mon, Feb 9, 2009 at 6:49 PM, Johannes Schindelin

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.
--

[ message continues ]

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
--

[ message continues ]

Maybe there should be a way to update it afterwards.

Santi
--

[ message continues ]

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

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
--

[ message continues ]

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


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

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
--

[ message continues ]

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

Yeah, as I said in the other mail, having it as a default would make add

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

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

Yeah, would make sense.

Björn
--

[ message continues ]

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

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


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
--

[ message continues ]

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
--

[ message continues ]

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

-Peff
--

[ message continues ]