From: Jonathan Nieder <jrnieder@gmail.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Git List <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: [RFC/PATCH] push: introduce implicit push
Date: Mon, 15 Apr 2013 19:05:15 -0700 [thread overview]
Message-ID: <20130416020515.GE3262@elie.Belkin> (raw)
In-Reply-To: <CALkWK0nNn_dGgr8F-kcQZm9UfkZAKwBd0bPSW9yCex4L9F+4Qw@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>> That "changing the meaning of <name>" in the middle, and doing so
>> will be confusing to the users, is exactly the issue, isn't it?
>
> Yes, but we have to change _something_ if we don't want to hit a WTF
> like 'git push master next' pushing master and next to
> branch.<HEAD>.pushremote.
Yep. In the usual case, all relevant remotes are "origin" anyway, so
there's no confusion. In the confusing cases it would be safer to
error out and give the user a hint about how to make the configuration
less confusing.
The manual could say:
In olden times, each [branch "<name>"] section would often have
its own remote and pushRemote settings. Ordinary branch creation
even created such a configuration. Nowadays that is
discouraged: we have found that it is less confusing in
practice to:
A) Typically fetch from one remote "[remote] default = origin"
and push to another "[remote] pushDefault = personal".
B) In atypical cases, explicitly name the remote being used
on the command line.
Thinking more, I suspect there is an asymmetry between "fetch" and
"push" here that we missed. The manual could say:
In typical usage, a person ordinarily pushes to a single
preferred publication point. You can set your publication
point using the "[remote] pushDefault" setting:
[remote]
pushDefault = myserver.example.com:/path/to/repo.git
To push a collection of branches to that remote repository,
pass a list of branch names to "git push" with a
disambiguating "--" to ensure the first branch name is not
treated as a remote name:
git push -- master next pu
For historical reasons, if "[remote] pushDefault" is not set,
it defaults to the remote that the branch being pushed is set
to pull from (its "upstream"). If pushDefault is unset and
multiple branches being pushed have different upstream
repositories, Git will error out to allow you to disambiguate.
To push to a different remote repository, just name it
explicitly on the command line.
git push korg -- master next pu
The asymmetry is because a command like "git fetch -- master next pu"
doesn't make much sense, since you have to know what remote you
fetched from to act on the fetch result.
As you hinted before, this would involve reverting the introduction
of "branch.<name>.pushremote", with the explanation that it was a
mistake inspired by that false symmetry, that you noticed and were
uncomfortable with but the rest of us were blind too.
Does that make sense?
Jonathan
next prev parent reply other threads:[~2013-04-16 2:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-12 15:33 [RFC/PATCH] push: introduce implicit push Ramkumar Ramachandra
2013-04-12 22:28 ` Junio C Hamano
2013-04-13 4:49 ` Ramkumar Ramachandra
2013-04-14 4:42 ` Junio C Hamano
2013-04-14 8:33 ` Jakub Narębski
2013-04-14 13:29 ` Ramkumar Ramachandra
2013-04-15 3:04 ` Junio C Hamano
2013-04-15 7:07 ` Johannes Sixt
2013-04-15 7:20 ` Junio C Hamano
2013-04-15 8:35 ` John Keeping
2013-04-15 9:17 ` Ramkumar Ramachandra
2013-04-15 9:46 ` John Keeping
2013-04-15 9:29 ` Junio C Hamano
2013-04-15 9:44 ` Ramkumar Ramachandra
2013-04-15 9:59 ` John Keeping
2013-04-15 16:39 ` Felipe Contreras
2013-04-15 17:13 ` John Keeping
2013-04-15 17:18 ` Felipe Contreras
2013-04-15 9:35 ` Ramkumar Ramachandra
2013-04-16 2:05 ` Jonathan Nieder [this message]
2013-04-16 2:13 ` Jonathan Nieder
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=20130416020515.GE3262@elie.Belkin \
--to=jrnieder@gmail.com \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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).