All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Carlos Martín Nieto" <cmn@elego.de>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.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: <1342019640.6458.23.camel@centaur.cmartin.tk> (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

  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 \
    --in-reply-to=1342019640.6458.23.camel@centaur.cmartin.tk \
    --to=cmn@elego.de \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --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.