patchbuiltin-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 <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(-)

Hi,

On Mon, 9 Feb 2009, Jay Soffian wrote:

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

Ciao, Dscho

Hi,

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

Cheers,

Mark

(Please don't trim cc:)

On Mon, Feb 9, 2009 at 7:03 PM, Mark Burton <markb@ordern.com> wrote:

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 Mon, 9 Feb 2009 19:22:50 -0500 Jay Soffian <jaysoffian@gmail.com> wrote:

How about the colour blind git users?

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

Mark Burton <markb@ordern.com> writes:

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

2009/2/10 Junio C Hamano <gitster@pobox.com>:

For me it makes sense.

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

Santi

On Mon, Feb 9, 2009 at 6:49 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

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.

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

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 <B.Steinbrink@gmx.de>:

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

Maybe there should be a way to update it afterwards.

Santi

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

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.

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

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

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

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:

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.

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

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.

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.

Yeah, would make sense.

Björn

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

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.

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.

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

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:

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:

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

-Peff