From: Jeff King <peff@peff.net>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Jonathan Nieder" <jrnieder@gmail.com>,
"Git List" <git@vger.kernel.org>,
"Duy Nguyễn" <pclouds@gmail.com>
Subject: Re: [ITCH] Specify refspec without remote
Date: Wed, 10 Apr 2013 16:24:56 -0400 [thread overview]
Message-ID: <20130410202456.GF24177@sigill.intra.peff.net> (raw)
In-Reply-To: <CALkWK0mEe+p3RX2tamW8dmdY_eP74Rdh_pZDRDPNfzX0TOKQCQ@mail.gmail.com>
On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote:
> > Right, the example above might include multiple remotes if pushremote is
> > respected. Or it might not come up with an answer at all for a tag.
> > If you do:
> >
> > git push -- v1.2.3 master
> >
> > where does v1.2.3 go? To remote.pushdefault? That seems simple and
> > consistent, as there is no ref-specific pushremote defined.
>
> remote.pushdefault indeed.
>
> > But I'd
> > guess that the user probably _wanted_ it to go to
> > branch.master.pushremote.
>
> Huh, why? Simply because he specified master alongside it? How can
> we infer what you said in a consistent system?
That's kind of my point. Why would they put two refs together in a
single push command? Did they mean "I am pushing up master, and since I
just tagged it, send the tag along, too"? Or did they really mean to
push them to two different places? If so, why not just run two separate
push commands?
I am not saying git should guess that the user wanted the tag to along
with master. I am saying that the set of rules to come to that
conclusion is going to be too baroque for the user to understand, and
too often wrong in other cases, and that we should not go there.
-Peff
next prev parent reply other threads:[~2013-04-10 20:25 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-18 16:58 [ITCH] Specify refspec without remote Ramkumar Ramachandra
2013-03-18 17:08 ` Jeff King
2013-03-19 9:58 ` Ramkumar Ramachandra
2013-03-19 10:02 ` Jeff King
2013-03-19 11:33 ` Duy Nguyen
2013-03-19 11:53 ` Ramkumar Ramachandra
2013-03-19 12:15 ` Duy Nguyen
2013-03-19 13:03 ` Holger Hellmuth (IKS)
2013-03-19 11:58 ` Holger Hellmuth (IKS)
2013-03-19 15:43 ` Junio C Hamano
2013-03-19 15:43 ` Junio C Hamano
2013-04-09 11:44 ` Ramkumar Ramachandra
2013-04-09 17:31 ` Junio C Hamano
2013-04-09 17:39 ` Ramkumar Ramachandra
2013-04-09 17:58 ` Junio C Hamano
2013-04-09 18:03 ` Ramkumar Ramachandra
2013-04-09 18:08 ` Ramkumar Ramachandra
2013-04-09 19:29 ` Junio C Hamano
2013-04-09 23:13 ` Jonathan Nieder
2013-04-09 23:14 ` Jonathan Nieder
2013-04-10 1:19 ` Junio C Hamano
2013-04-10 4:13 ` Jeff King
2013-04-10 16:37 ` Junio C Hamano
2013-04-10 17:27 ` Jeff King
2013-04-10 18:54 ` Junio C Hamano
2013-04-10 18:59 ` Jeff King
2013-04-10 19:31 ` Ramkumar Ramachandra
2013-04-10 19:33 ` Ramkumar Ramachandra
2013-04-10 19:52 ` Jeff King
2013-04-10 20:05 ` Ramkumar Ramachandra
2013-04-10 20:21 ` Jeff King
2013-04-10 20:41 ` Ramkumar Ramachandra
2013-04-10 21:02 ` Ramkumar Ramachandra
2013-04-10 21:32 ` Ramkumar Ramachandra
2013-04-10 20:21 ` Junio C Hamano
2013-04-10 19:53 ` Ramkumar Ramachandra
2013-04-10 20:05 ` Jonathan Nieder
2013-04-10 20:11 ` Jeff King
2013-04-10 21:23 ` Jonathan Nieder
2013-04-10 20:05 ` Jeff King
2013-04-10 20:19 ` Ramkumar Ramachandra
2013-04-10 20:24 ` Jeff King [this message]
2013-04-10 20:55 ` Ramkumar Ramachandra
2013-04-10 21:04 ` Jeff King
2013-04-10 21:11 ` Ramkumar Ramachandra
2013-04-10 21:18 ` Jonathan Nieder
2013-04-10 21:23 ` Ramkumar Ramachandra
2013-04-10 21:29 ` Jonathan Nieder
2013-04-10 21:42 ` Ramkumar Ramachandra
2013-04-10 21:56 ` Jeff King
2013-04-10 22:06 ` Ramkumar Ramachandra
2013-04-10 22:16 ` Jeff King
2013-04-10 22:11 ` Ramkumar Ramachandra
2013-04-10 22:23 ` Jeff King
2013-04-10 22:31 ` Ramkumar Ramachandra
2013-04-11 7:38 ` Ramkumar Ramachandra
2013-04-11 7:45 ` Ramkumar Ramachandra
2013-04-11 21:40 ` Junio C Hamano
2013-04-13 5:07 ` Ramkumar Ramachandra
2013-04-10 20:27 ` Junio C Hamano
2013-04-10 21:15 ` Ramkumar Ramachandra
2013-04-12 22:14 ` Junio C Hamano
2013-04-10 3:50 ` Jeff King
2013-04-10 13:22 ` Ramkumar Ramachandra
2013-04-10 15:56 ` Jeff King
2013-04-10 16:38 ` Junio C Hamano
2013-04-10 17:29 ` Jeff King
2013-04-10 13:19 ` Ramkumar Ramachandra
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=20130410202456.GF24177@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=pclouds@gmail.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 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.