From: Jay Soffian <jaysoffian@gmail.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [1.8.0] Change branch --set-uptream to take an argument
Date: Tue, 1 Feb 2011 16:14:07 -0500 [thread overview]
Message-ID: <AANLkTimOLPVp0EdhTsrPcF7gtykh3o-yE7KimBSJwfY3@mail.gmail.com> (raw)
In-Reply-To: <vpqzkqg5dsq.fsf@bauges.imag.fr>
On Tue, Feb 1, 2011 at 4:01 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Jay Soffian <jaysoffian@gmail.com> 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.
next prev parent reply other threads:[~2011-02-01 21:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 6:57 [1.8.0] Change branch --set-uptream to take an argument Jay Soffian
2011-02-01 9:01 ` Matthieu Moy
2011-02-01 21:14 ` Jay Soffian [this message]
2011-02-04 8:54 ` Stefan Haller
2011-02-01 21:15 ` Junio C Hamano
2011-02-01 21:27 ` Jay Soffian
2011-02-02 4:08 ` Miles Bader
2011-02-02 4:18 ` Jay Soffian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTimOLPVp0EdhTsrPcF7gtykh3o-yE7KimBSJwfY3@mail.gmail.com \
--to=jaysoffian@gmail.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).