git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "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: Tue, 10 Jul 2012 18:47:17 -0500	[thread overview]
Message-ID: <20120710234717.GA21467@burratino> (raw)
In-Reply-To: <7vehojgqgk.fsf@alter.siamese.dyndns.org>

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 branch.frotz.description, for
> example.  It would be used like this:
>
> 	$ git branch --set-description='add frotz feature' frotz

That's the same question.

You say that it would be used like that.  I say that it would be
more intuitive, given how "git remote", "git config", and other
commands other than "update-index --chmod" that set attributes already
work, for it to be used like this:

	git branch --set-description frotz 'add frotz feature'

Notice how similar that is to "git remote set-head origin master".
It would just be the consistent thing to do.

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.  The convention used for plain "git branch" is

	copy(target, source)

That matches memcpy() and is the opposite of what "cp" uses.  Oh
well.  The convention used for "git remote add" is

	method(this, args...)

It's generally pretty natural.  The convention used for "git
update-index --chmod" is

	action(parameters)(files...)

That matches "chmod" so it was probably a good choice.

Hoping that clarifies,
Jonathan

  reply	other threads:[~2012-07-10 23:47 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 [this message]
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
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
  -- strict thread matches above, loose matches on Subject: below --
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=20120710234717.GA21467@burratino \
    --to=jrnieder@gmail.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=cmn@elego.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).