On 2009.09.10 11:29:54 -0700, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
> > On Thu, Sep 10, 2009 at 12:18:06PM +0200, Johan Herland wrote:
> >
> >> > > A special shortcut '@{tracked}' refers to the branch tracked by the
> >> > > current branch.
> >> >
> >> > Sorry, I didn't know the name of the long form was up for discussion.
> >> > But it should certainly coincide with the key which for-each-ref
> >> > uses, shouldn't it? I don't care whether tracked or upstream, but
> >> > for-each-ref's "upstream" has set the precedent.
> >>
> >> ...and 'git branch --track' set an even earlier precedent...
> >
> > FWIW, that came about from this discussion:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/115765
>
> After re-reading the discussion in the thread that contains the quoted
> article, it sounds like we may want to fix "branch --track X Y". X does
> not "track" Y in the same sense as origin/master "tracks" master at
> origin. Rather, X builds on Y.
FWIW, I just had a discussion on #git with Jim Ramsay (lack) about that.
We agreed that "branch --track" is unfortunate and causes confusion,
when it comes to the term "tracking branch" (which the glossary
basically defines to be something in the refs/remotes/ namespace, at
least something you never commit to), as people also start to use that
for branch heads that have an "upstream branch" set in the
configuration.
Jim initially preferred the term "linked", while I argued for the option
to be called --upstream (potentially with the possibility to say
--upstream=rebase or --upstream=merge, the default being "merge", unless
branch.autosetuprebase is set).
We could (I think) to some degree agree that "upstream" is quite good,
although we couldn't find a short and sweet term to describe the branch
head that has a configured upstream branch (some ideas were "upstreamed
branch", "uplinked branch", "downstream branch" and some more, which I
all dislike). After having read the glossary and finding "upstream
branch" in there, I'm even more in favor of using the "upstream" term in
some form.
During the discussion, there were some requests (again) for a command
that allows to change branch.<name>.remote and branch.<name>.merge for
already existing branch heads. With that extra input, I'd now favor:
git branch --set-upstream X Y
because that's potentially reusable for the "change upstream for an
existing branch" case, though I'm totally clueless how to actually do
that, given that "git branch" uses flags to switch between "create new
branch" and "operate on existing branch". So reusing a flag won't
(easily) do the trick, at least not without special casing that could be
dangerous. You could, for example, accidently change the upstream for an
existing branch, while you meant to create a new one.
It's a bit sad that we don't have subcommands for "git branch" like we
do for "git remote", that would make the whole thing a lot easier, but
it's way too late to change that, I guess. At least having "git branch
<name>" default to be "git branch add <name>" would make some branch
names "invalid" for that shortform. So that looks like a no-go.
Björn
--
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