From: Jay Soffian <jaysoffian@gmail.com>
Date: Wed, 11 Mar 2009 02:59:01 GMT
Subject: Re: setting up tracking on push
Message-ID: <76718490903101959i61df26aagdff44bb9ab4593ab@mail.gmail.com>
In-Reply-To: <20090311020409.GA31365@coredump.intra.peff.net>

On Tue, Mar 10, 2009 at 10:04 PM, Jeff King <peff@peff.net> wrote:
>
>> -u --track [<branch>] <upstream>
>
> Hmm. This seems not quite right to me. Specifically:
>
>  1. Would you ever want to use "-u" without "--track"? If so, then why
>     are they two separate options?

For when branch grows additional long options that update, er,
something else. :-)

And you can also use it with --no-track.

But the primary reason for the -u is to differentiate the operation,
just like -m and -d.

>  2. In your example, if I give only a single non-option argument, it is
>     interpreted as the upstream (and presumably the branch defaults to
>     HEAD).  But in other branch commands, it is interpreted as the
>     branch, and the upstream defaults to HEAD.

No, look at how -m works. [<oldbranch>] <newbranch>. I modeled it after that.

> For (1), you could just have a single option. Unfortunately --track is
> taken. But maybe you could do --track=. And that helps with (2), as
> well, since this syntax would only ever have one or zero arguments. And
> then you can default zero to HEAD.
>
> IOW:
>
>  # track origin/master with the current branch
>  git branch --track=origin/master
>
>  # track origin/master with a different branch
>  git branch --track=origin/master other_branch
>
>  # stop tracking
>  git branch --track=
>
> The only two problems I can think of are:
>
>  1. It is perhaps a little confusing that --track= means "don't do the
>     normal branch operation, but instead do this totally different
>     thing. Of course we already have a similar situation with "-m", but
>     it is perhaps more confusing since "--track" and "--track=" have
>     totally different semantics.
>
>  2. This would be the only branch command to operate on HEAD if given
>     no argument. That isn't necessary for this proposal, but I think it
>     makes it nicer to use. An alternative would be for git-branch to
>     resolve symrefs (which would also be nice for "git branch -m HEAD
>     foo").

Yeah, I like that less than -u, which I agree isn't perfect, but I
think it's closer.

j.