Re: [1.8.0] Change branch --set-uptream to take an argument

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 1, 2011, 21:15 UTC
Message-ID: <7v7hdj1mo7.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTinUn2SMijphe3EmPMVOOwBjPB5ffFwwqZVxQmW0@mail.gmail.com>

Jay Soffian <jaysoffian@gmail.com> writes:

Show 9 quoted lines

> Proposal:
>
> Currently it is very easy to misinvoke --set-upstream if you assume it
> takes an argument:
>
> e.g.
>
>   (master)$ git branch --set-upstream origin/master
>   Branch origin/master set up to track local branch master.

With "git branch <name>" (or for that matter "git branch -d <name>"), we are manipulating some attribute of the branch <name> (namely, "what does it point at", "does it exist?") not of the current branch. So it is natural to expect that some attribute of the named branch origin/master is being changed.

> In order to make its usage unambiguous, and to allow it to be used w/o
> specifying the current branch, require it to take an argument like so:
>
>   (master)$ git branch --set-upstream=origin/master

Even though I think I understand the issue you are trying to tackle, I think your proposal seems to make things worse. In either "--set-upstream A" or "--set-upstream=A", it is unclear if you are manipulating "what other branch does this follow" attribute of A or the current branch.

I think it was a misdesign to allow --set-upstream without argument to default to the current branch. Wouldn't it be simpler to just fix the parser so that "--set-upstream A" and "--set-upstream=A" both mean the same thing? The branch whose attribute is manipulated defaults to the current one in either case.

IOW, I don't think

>   (master)$ git branch --set-upstream origin/master
>   Branch origin/master set up to track local branch master.

is a sane behaviour from day one, and is simply a bug. Changing this behaviour would merely be a bugfix, not a flag-day event that changes an established behaviour.

But that may be just me. I don't use --set-upstream myself, and people may have learned to be comfortable with the current behaviour.

        If there are people who want to keep the current behaviour, please
        speak up.  Then we can introduce the usual migration procedure to
        first add a configuration to flip the behaviour (default off),
        then warn if you use 0-argument --set-upstream to default to the
        current branch without setting the configuration, and eventually
        flip the default to always require argument to --set-upstream.

> (I've misinvoked it so often, I've had to train myself to always
> invoke it this way: git branch master --set-upstream origin/master)

If "git branch master --set-upstream origin/master" is accepted, we have another bug in its parser to fix. The canonical command line should always be dashed-options, then refs and then pathspecs.