All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.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 16:13:15 -0700	[thread overview]
Message-ID: <7vehojgqgk.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20120710210901.GI8439@burratino> (Jonathan Nieder's message of "Tue, 10 Jul 2012 16:09:01 -0500")

Jonathan Nieder <jrnieder@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" 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

to set the description for the 'frotz' branch (i.e. the above would
set branch.frotz.description), and we default to HEAD if 'frotz' is
missing from the command line.  "git branch --option [<branch>]" is
about manipulating the branch, and we default the target of
manipulation to HEAD.

"upstream" is just another kind of attribute for the branch being
manipulated, whose value happens to be a branch name.

The mistake was that --set-upstream was coded by piggybacking the
existing --track implementation where a new branch was created, and
in that codepath, "git branch <name1> [<name2>]" creates <name1>
while defaulting a missing <name2> to HEAD.

Creating a new branch that is forked from the current HEAD is an
often useful thing to do, so defaulting a missing <name2> (aka
"start-point") to HEAD is very sensible, but reconfiguring a named
branch <name1> to integrate with the current branch is much less
useful than the other way around.  One major reason why it is so is
because you would more likely set any branch to integrate with a
remote tracking branch (rather than a local branch) and by
definition your HEAD cannot be a remote tracking branch.

It makes it worse that you would often want to reconfigure the
current branch; for the purpose of reconfiguring a branch <name1> to
integrate with something else <name2>, it is much more likely that
you want a missing <name1> to default to HEAD, not the other way
around to default a missing <name2> to HEAD, which is useful for
branch creation.

But switching which missing argument gets default based on what
options are used is insane.

If the very original "create this new branch starting at that point"
were spelled like this

	$ git branch [--start-point=<name2>] <name1>

and a missing <name2> defaulted to HEAD, it probably would have been
better. It would have made it very unlikely to tempt anybody to hack
the --set-upstream option into the system with the wrong parameter
order if such a command line convention was in place.

If anything, it could be a sensible longer-term direction to a more
intuitive UI to deprecate the two-name format and make the creation
to be specified with an explicit --start-point option with an
argument (which defaults to HEAD), but I think that falls into the
"if I were reinventing git without existing userbase in 2005"
category and it is too late for that.

  reply	other threads:[~2012-07-10 23:13 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 [this message]
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
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=7vehojgqgk.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 \
    --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.