From: "Jakub Narębski" <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Ramkumar Ramachandra <artagnon@gmail.com>,
Git List <git@vger.kernel.org>, Jeff King <peff@peff.net>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [RFC/PATCH] push: introduce implicit push
Date: Sun, 14 Apr 2013 10:33:39 +0200 [thread overview]
Message-ID: <516A69E3.2090805@gmail.com> (raw)
In-Reply-To: <7vehed7ilu.fsf@alter.siamese.dyndns.org>
W dniu 14.04.2013 06:42, Junio C Hamano pisze:
> I personally think it is much more sellable to use an even simpler
> rule than what Jeff suggested, to make
>
> git push -- <refspec>
>
> go to the remote.pushdefault (falling back to remote.default that is
> "origin"), without even paying attention to what branch you are on,
> and ignoring branch.*.remote/pushremote configuration.
>
> That is sufficient to support the triangular, the publish-to-mine,
> and the centralized workflows, no? In any of these cases, the
> repository you push out to is _one_, even though it may be a
> different one from where you pull from. If you have a very special
> branch that goes to a different place than all the other branches,
> you can always push out while on that branch without any refspec,
> anyway.
I think it also supports users of 'matching' that have push default
correctly configured. Currently they can use "git push" in all cases
but first push of a branch, where they had to use "git push origin
branch", or "git push pushremote branch", and with those changes can
now simply use "git push -- branch".
Nice.
Here I think simpler is better, especially that diferent users
have different expectations: push to remote based on current branch or
push to remote or remotes based on branch or branches being pushed.
--
Jakub Narębski
next prev parent reply other threads:[~2013-04-14 8:34 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 [this message]
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
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=516A69E3.2090805@gmail.com \
--to=jnareb@gmail.com \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.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 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.