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

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

Jeff King [off-list ref] writes:

quoted

On Thu, Sep 10, 2009 at 12:18:06PM +0200, Johan Herland wrote:

quoted

quoted

quoted

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