Junio C Hamano writes:
> Ralf Thielow writes:
>
>> On Fri, Aug 31, 2012 at 5:22 PM, Carlos Martín Nieto wrote:
>>> Ralf Thielow writes:
>>>
On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto wrote:
> behaviour. To work around this, introduce --set-upstream-to which
> accepts a
Ralf Thielow writes:
> On Fri, Aug 31, 2012 at 5:22 PM, Carlos Martín Nieto wrote:
>> Ralf Thielow writes:
>>
>>> On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto wrote:
behaviour. To work around this, introduce --set-upstream-to which
accepts a compulsory argument indicating wha
On Fri, Aug 31, 2012 at 5:22 PM, Carlos Martín Nieto wrote:
> Ralf Thielow writes:
>
>> On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto wrote:
>>> behaviour. To work around this, introduce --set-upstream-to which
>>> accepts a compulsory argument indicating what the new upstream branch
>>>
Ralf Thielow writes:
> On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto wrote:
>> behaviour. To work around this, introduce --set-upstream-to which
>> accepts a compulsory argument indicating what the new upstream branch
>> should be and one optinal argument indicating which branch to change
On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto wrote:
> behaviour. To work around this, introduce --set-upstream-to which
> accepts a compulsory argument indicating what the new upstream branch
> should be and one optinal argument indicating which branch to change,
> defaulting to HEAD.
>
C
The existing --set-uptream option can cause confusion, as it uses the
usual branch convention of assuming a starting point of HEAD if none
is specified, causing
git branch --set-upstream origin/master
to create a new local branch 'origin/master' that tracks the current
branch. As --set-upstre
The existing --set-uptream option can cause confusion, as it uses the
usual branch convention of assuming a starting point of HEAD if none
is specified, causing
git branch --set-upstream origin/master
to create a new local branch 'origin/master' that tracks the current
branch. As --set-upstre
Miles Bader writes:
> Junio C Hamano writes:
>> is easier to understand, while I think
>>
>> git branch []
>> git branch --set-upstream-to= []
>
> Isn't one problem with this that even if a "--set-upstream-to" option
> exists, inevitably some [and I'm guessing, many] people will no
Junio C Hamano writes:
> is easier to understand, while I think
>
> git branch []
> git branch --set-upstream-to= []
Isn't one problem with this that even if a "--set-upstream-to" option
exists, inevitably some [and I'm guessing, many] people will not be
aware of it (after all, nob
Junio C Hamano wrote:
> In short, you are saying that, assuming that missing and
> are given a sane default values (namely "HEAD"), the
> syntax:
>
> git branch []
> git branch --set-upstream-jrn []
>
> is easier to understand
I didn't propose allowing the branch argument to be om
Jonathan Nieder writes:
> The truth is that neither one of us is right. Both conventions
> could work, and which one is more intuitive will vary from person
> to person.
It is not just person-to-person, I think.
In short, you are saying that, assuming that missing and
are given a sane defaul
Junio C Hamano wrote:
> You can think of it this way.
>
> "git branch" can not only _create_ a new branch (or list existing
> ones, but that is another entirely different mode), but also can be
> used to set attributes to an existing branch. Imagine a new option,
> say --set-description, to repla
Jonathan Nieder writes:
> [someone should have]
> | suggested an alternative syntax that avoids the mistake you quoted
> | above, perhaps something like:
> |
> | git branch --set-upstream-to=origin/master [HEAD]
>
> with which I disagree.
You can think of it this way.
"git branch" can not o
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> The immediate problem that seems to trip people up is that it is very
>> tempting to run
>>
>> git branch --set-upstream junio/master
>
> I think we have discussed this already a few days ago. See my
> comment in the earlier thread before t
Jonathan Nieder writes:
> The immediate problem that seems to trip people up is that it is very
> tempting to run
>
> git branch --set-upstream junio/master
I think we have discussed this already a few days ago. See my
comment in the earlier thread before this round.
--
To unsubscribe fro
Junio C Hamano wrote:
> I am not super excited about it either, but at least it is a vast
> improvement compared to the older one, with which it was entirely
> unclear if we are setting the value of upstream *to* what is given
> as an option, or setting the upstream *for* what is given on the
> co
Jonathan Nieder writes:
>> The existing --set-uptream option can cause confusion, as it uses the
>> usual branch convention of assuming a starting point of HEAD if none
>> is specified, causing
>>
>> git branch --set-upstream origin/master
>>
>> to create a new local branch 'origin/master' th
Hi,
Carlos Martín Nieto wrote:
> The existing --set-uptream option can cause confusion, as it uses the
> usual branch convention of assuming a starting point of HEAD if none
> is specified, causing
>
> git branch --set-upstream origin/master
>
> to create a new local branch 'origin/master' th
Carlos Martín Nieto writes:
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 0e060f2..c886fc0 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -713,6 +713,7 @@ int cmd_branch(int argc, const char **argv, const char
> *prefix)
> int verbose = 0, abbrev = -1, detached
Carlos Martín Nieto writes:
> The new options allows us to type
>
> git branch --set-upstream-to origin/master
This is cool :-).
> Documentation/git-branch.txt |9 -
> builtin/branch.c | 15 +--
I think this deserves a few new tests (probably in t/t320
The existing --set-uptream option can cause confusion, as it uses the
usual branch convention of assuming a starting point of HEAD if none
is specified, causing
git branch --set-upstream origin/master
to create a new local branch 'origin/master' that tracks the current
branch. As --set-upstre
21 matches
Mail list logo
