From: "Carlos Martín Nieto" <email@example.com> To: Jonathan Nieder <firstname.lastname@example.org> Cc: Junio C Hamano <email@example.com>, firstname.lastname@example.org, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Subject: Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch Date: Wed, 11 Jul 2012 17:14:00 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <20120710230014.GA20873@burratino> On Tue, 2012-07-10 at 18:00 -0500, Jonathan Nieder wrote: > Junio C Hamano wrote: > > > I think it > > is better to leave them emitted unconditionally to the standard > > error stream, in order to train users away from using the old option > > that has its arguments wrong (the option does not take an argument > > it should, and makes the command line to look as if it takes two > > branch arguments in the wrong order). > > I thought we already discussed that that is a side-issue? The current --set-upstream is the whole reason for this series existing. > > The option is a mode option for the command, like "-m", "-d", or > "--edit-description". I genuinely don't think the order of options it > takes is counter-intuitive. The second argument defaulting to HEAD > and the behavior of creating the branch named by the first argument > when it does not exist are quite counter-intuitive. This is confusing. First you say that you don't think it's counter-intuitive but then you say it is? Or is the first part about -m and -d? The second part of the paragraph is indeed what I'm trying to solve with this series. If you want to create a new branch, you should be using -t. > > Transitioning to a different argument order seems like it would just > make the command more complicated. After the transition, there are > two options to explain, and during the transition, it is easy to make > scripts with gratuitous incompatibilities that won't work on older > systems. > > Where is my thinking going wrong? We're not transitioning to a new order as such, particularly not with the same option name. The incompatibilities would ensue with the other patch I send which did change the order for --set-upstream, but what this does is _add_ --set-upstream-to=<upstream> such that the option takes one argument and the command takes one optional argument, which makes it closer to what one would expect, specially as changing the upstream information is something you're most likely to do on the current branch. cmn
next prev parent reply other threads:[~2012-07-11 15:13 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-10 16:52 [PATCH 0/3] A better way of handling upstream information in git-branch Carlos Martín Nieto 2012-07-10 16:52 ` [PATCH 1/3] branch: introduce --set-upstream-to Carlos Martín Nieto 2012-07-10 17:08 ` Matthieu Moy 2012-07-10 17:26 ` Junio C Hamano 2012-07-10 19:13 ` Jonathan Nieder 2012-07-10 19:49 ` Junio C Hamano 2012-07-10 20:11 ` Jonathan Nieder 2012-07-10 20:49 ` Junio C Hamano 2012-07-10 21:09 ` Jonathan Nieder 2012-07-10 23:13 ` Junio C Hamano 2012-07-10 23:47 ` Jonathan Nieder 2012-07-11 1:20 ` Junio C Hamano 2012-07-11 1:37 ` Jonathan Nieder 2012-07-12 8:41 ` Miles Bader 2012-07-12 16:58 ` Junio C Hamano 2012-07-10 16:53 ` [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch Carlos Martín Nieto 2012-07-10 17:20 ` Matthieu Moy 2012-07-11 13:50 ` Carlos Martín Nieto 2012-07-10 17:40 ` Junio C Hamano 2012-07-11 14:24 ` Carlos Martín Nieto 2012-07-10 19:24 ` Jonathan Nieder 2012-07-10 22:43 ` Junio C Hamano 2012-07-10 23:00 ` Jonathan Nieder 2012-07-11 15:14 ` Carlos Martín Nieto [this message] 2012-07-10 16:53 ` [PATCH 3/3] branch: add --unset-upstream option Carlos Martín Nieto 2012-07-10 18:02 ` Junio C Hamano 2012-07-11 14:14 ` Carlos Martín Nieto 2012-07-11 16:53 ` Junio C Hamano 2012-07-12 10:27 ` Carlos Martín Nieto
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 \ --firstname.lastname@example.org \ --email@example.com \ --cc=Matthieu.Moy@grenoble-inp.fr \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch' \ /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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.