"Pat Notz" <pknotz@xxxxxxxxxx> writes:
> This version fixes the verbose output to be more human friendly. Before,
> the branch being tracked was printed as 'refs/heads/frotz' regardless of
> wether that was a local or remote branch. Now, a local branch is just
> printed as 'frotz' and a remote branch is printed as 'origin/frotz'
Since I've already queued the previous round in 'next', I took the liberty
of making this into an incremental.
I do not think what you did is really correct. For clone, because we do
not create anything but the default "refs/remotes/<origin>/<branch>"
layout, always stripping out the first 11 bytes "refs/heads/" happens to
give a more intuitive result. But the helper function is shared with a
more general "git branch --track" that lets you mark the new branch to
track almost anything. For example, the version from v1.6.0 gives you
these:
$ git branch --track maint-1.6.0 v1.6.0
Branch maint-1.6.0 set up to track local branch refs/tags/v1.6.0
$ git branch --track frotz master
Branch frotz set up to track local branch refs/heads/master
Arguably, the former should say "track local ref refs/tags/v1.6.0" (or the
command should not even let you "track" a tag, which is supposed to be
immutable), and the latter would be helped by stripping "refs/heads/".
But the point is that stripping first 11 bytes unconditionally would be
wrong if you happen to start tracking a tag whose name is a single byte.
Also I do not think ("%s/%s", origin, remote+11) is correct in general.
You could very well configure your tracking to:
[remote "origin"]
fetch = refs/heads/*:refs/remotes/upstream/*
and I think the variable "remote" here refer to the name the ref is known
as in the remote repository, not the name we use to keep a copy of. IOW,
when we say "Branch frotz tracks remote 'master'", we should say "the
branch known as 'master' at the remote site, no matter what name we happen
to call its copy locally somewhere under our refs/remotes".
In that sense, both the version I queued and the original are lacking
a critical piece of information: which remote we are talking about.
In any case, here is your patch, made into an incremental. I'll send out
an alternative fix in a separate message.
branch.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/branch.c b/branch.c
index d20fb04..d586843 100644
--- a/branch.c
+++ b/branch.c
@@ -65,12 +65,18 @@ void install_branch_config(int flag, const char *local, const char *origin, cons
git_config_set(key.buf, "true");
}
- if (flag & BRANCH_CONFIG_VERBOSE)
+ if (flag & BRANCH_CONFIG_VERBOSE) {
+ strbuf_reset(&key);
+ if (origin)
+ strbuf_addf(&key, "%s/%s", origin, remote+11);
+ else
+ strbuf_addf(&key, "%s", remote+11);
printf("Branch %s set up to track %s branch %s %s.\n",
local,
origin ? "remote" : "local",
- remote,
+ key.buf,
rebasing ? "by rebasing" : "by merging");
+ }
strbuf_release(&key);
}
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
