Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Oct 2, 2009, 14:54 UTC
Message-ID: <20091002145444.GA27904@atjola.homenet>
In-Reply-To: <7vzl92bql9.fsf@alter.siamese.dyndns.org>

On 2009.09.10 11:29:54 -0700, Junio C Hamano wrote:

Show 22 quoted lines

> Jeff King <peff@peff.net> 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