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

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

[Jay Soffian]

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

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

[Johannes Schindelin]

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

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

[Mark Burton]

Hi,

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

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

[Jay Soffian]

On Mon, Feb 9, 2009 at 6:49 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> 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...

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.

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

[Jay Soffian]

(Please don't trim cc:)

On Mon, Feb 9, 2009 at 7:03 PM, Mark Burton <markb@ordern.com> 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.

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

[Junio C Hamano]

Mark Burton <markb@ordern.com> writes:

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

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

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

[Björn Steinbrink]

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

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

[Santi Béjar]

2009/2/10 Junio C Hamano <gitster@pobox.com>:
> Mark Burton <markb@ordern.com> writes:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.
>
> 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

For me it makes sense.

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

Santi

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

[Santi Béjar]

2009/2/10 Björn Steinbrink <B.Steinbrink@gmx.de>:
> 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,

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

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

[Björn Steinbrink]

On 2009.02.10 09:02:02 +0100, Santi Béjar wrote:
> 2009/2/10 Björn Steinbrink <B.Steinbrink@gmx.de>:
> > 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,
> 
> 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.

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

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

[Mark Burton]

On Mon, 9 Feb 2009 19:22:50 -0500
Jay Soffian <jaysoffian@gmail.com> wrote:

> (Please don't trim cc:)
> 
> On Mon, Feb 9, 2009 at 7:03 PM, Mark Burton <markb@ordern.com> 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. 

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

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

[Jeff King]

[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

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

[Björn Steinbrink]

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

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

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

[Jeff King]

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.

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

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

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

[Björn Steinbrink]

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

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

[Jeff King]

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

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