On Tue, Feb 1, 2011 at 4:01 AM, Matthieu Moy
<Matthieu.Moy@xxxxxxxxxxxxxxx> wrote:
> Jay Soffian <jaysoffian@xxxxxxxxx> writes:
>
>> Currently it is very easy to misinvoke --set-upstream if you assume it
>> takes an argument:
>
> Your proposal sounds interesting, but I'd like to see something more
> global: right now, some commands take a --track option and other take
> a --set-upstream. In short, I'd like to see this --track deprecated
> (since it's not actually about remote-tracking ...).
There are a few things at work here. --track/--no-track are used to
override the branch.autosetupmerge configuration and are supported by
checkout and branch. --set-upstream is only supported by branch, and
is subtly different from --track.
There is also branch.autosetuprebase, for which there is no
command-line option to override.
These options/configs control how branch.<name>.{merge,remote,rebase}
are set. --track/--no-track only take effect when the branch is
created. --set-upstream can be used when the branch is created, or
after the fact.
(Aside, the names of the config params are starting to look
sub-optimal, but it's probably not worth the pain of changing them.)
I suppose a more comprehensive proposal looks like this:
1. Deprecate --track and --no-track (remove from documentation and
usage). I wonder if anyone ever uses them?
2. Deprecate --set-upstream as its usage is confusing.
3. Add -u <name> to both checkout and branch to specify the upstream
branch. It is used with checkout -b in cases where an upstream would
not normally be configured, either because it's not the default
according to branch.autosetupmerge or because the start-point is not a
branch. It is used with branch when creating a branch in a similar
manner to how it's used with checkout when creating a branch, but may
also be used to reset the upstream after the fact like so:
$ git branch -u <upstream> [<branch>]
4. Add --pull-default={rebase,merge} to both checkout and branch used
for setting/unsetting branch.<name>.rebase during initial branch
creation, or after the fact in the case of git-branch. It is an error
to try to set --pull-default if the upstream is not configured, either
automatically or via -u.
>> (Though I'm not sure whether the options parser allows for both
>> --set-upstream and --set-upstream=<arg>)
>
> There are already many instances of this. When <arg> is mandatory, you
> can write either --option <arg> or --option=<arg> (like "git log
> --grep pattern" Vs "git log --grep=pattern"), and when <arg> is
> optional, you can write either --option alone, or --option=<arg> (like
> "git diff --color-words" and "git diff --color-words=.").
Sorry. What I meant was that you'd need the ability to differentiate
between "--set-upstream=foo" and "--set-upstream foo" due to
git-branch's existing semantics. Right now:
$ git branch --set-upstream topic origin/master
Creates topic from origin/master and sets topic's upstream to
origin/master. If --set-upstream suddenly starts taking an argument,
that means something completely different: create a new branch named
origin/master starting at HEAD and set its upstream to "topic".
I think we're better off just deprecating --set-upstream and
introducing the more convenient -u.
j.
--
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