Ralf Thielow ralf.thie...@gmail.com writes:
On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto c...@elego.de 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
On Fri, Aug 31, 2012 at 5:22 PM, Carlos Martín Nieto c...@elego.de wrote:
Ralf Thielow ralf.thie...@gmail.com writes:
On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto c...@elego.de wrote:
behaviour. To work around this, introduce --set-upstream-to which
accepts a compulsory argument
Ralf Thielow ralf.thie...@gmail.com writes:
On Fri, Aug 31, 2012 at 5:22 PM, Carlos Martín Nieto c...@elego.de wrote:
Ralf Thielow ralf.thie...@gmail.com writes:
On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto c...@elego.de wrote:
behaviour. To work around this, introduce
On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto c...@elego.de 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
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
Junio C Hamano gits...@pobox.com writes:
is easier to understand, while I think
git branch branch [start]
git branch --set-upstream-to=upstream [branch]
Isn't one problem with this that even if a --set-upstream-to option
exists, inevitably some [and I'm guessing, many] people
Miles Bader mi...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
is easier to understand, while I think
git branch branch [start]
git branch --set-upstream-to=upstream [branch]
Isn't one problem with this that even if a --set-upstream-to option
exists, inevitably
Carlos Martín Nieto c...@elego.de 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,
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' that
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
Jonathan Nieder jrnie...@gmail.com 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
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
Jonathan Nieder jrnie...@gmail.com 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
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 replace
Jonathan Nieder jrnie...@gmail.com 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 start and
Junio C Hamano wrote:
In short, you are saying that, assuming that missing start and
branch are given a sane default values (namely HEAD), the
syntax:
git branch branch [start]
git branch --set-upstream-jrn [branch] upstream
is easier to understand
I didn't propose allowing
16 matches
Mail list logo
