Jay Soffian <jaysoffian@xxxxxxxxx> writes:
> 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.
--
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