All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Miles Bader <miles@gnu.org>
Cc: "Jonathan Nieder" <jrnieder@gmail.com>,
	"Carlos Martín Nieto" <cmn@elego.de>,
	git@vger.kernel.org,
	"Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [PATCH 1/3] branch: introduce --set-upstream-to
Date: Thu, 12 Jul 2012 09:58:37 -0700	[thread overview]
Message-ID: <7v394wdigy.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <874npds75j.fsf@catnip.gol.com> (Miles Bader's message of "Thu, 12 Jul 2012 17:41:44 +0900")

Miles Bader <miles@gnu.org> writes:

> Junio C Hamano <gitster@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 will not be
> aware of it (after all, nobody reads documentation more than they have
> to), and will attempt to use "--set-upstream" with an argument
> (that's the natural thing to do, after all) -- which may succeed with
> weird results ...?

In the part you quoted in the message you are responding to in the
subthread between Jonathan and, I was expressing doubts about his
"upon seeing a single argument for operations that need two pieces
of info, sometimes the first one is assumed to be missing and gets
the default, some other times the second one is assumed to be
missing and gets the default" design, which I felt would be
unnecessarily confusing.

The issue of possible confusion you raised is real, was discussed in
the main thread of discussion of the earlier round, and has been
addressed in this round of the patch series, I think, with warnings
and/or advises.

  reply	other threads:[~2012-07-12 16:58 UTC|newest]

Thread overview: 36+ 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 [this message]
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
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
2012-08-20 13:47 [PATCH 0/3] Improve branch UI for setting upstream information Carlos Martín Nieto
2012-08-20 13:47 ` [PATCH 1/3] branch: introduce --set-upstream-to Carlos Martín Nieto
2012-08-30 17:23 [PATCHv2 0/3] Improve branch UI for setting upstream information Carlos Martín Nieto
2012-08-30 17:23 ` [PATCH 1/3] branch: introduce --set-upstream-to Carlos Martín Nieto
2012-08-30 17:51   ` Ralf Thielow
2012-08-31 15:22     ` Carlos Martín Nieto
2012-08-31 15:30       ` Ralf Thielow
2012-08-31 17:09         ` Junio C Hamano
2012-09-01 15:13           ` 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=7v394wdigy.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=cmn@elego.de \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=miles@gnu.org \
    --subject='Re: [PATCH 1/3] branch: introduce --set-upstream-to' \
    /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.