From: Jeff King <peff@peff.net>
To: David Lee <davidomundo@gmail.com>
Cc: Sverre Rabbelier <srabbelier@gmail.com>, git@vger.kernel.org
Subject: Re: Separate default remotes for pulling and pushing
Date: Mon, 9 May 2011 07:10:19 -0400 [thread overview]
Message-ID: <20110509111019.GD9060@sigill.intra.peff.net> (raw)
In-Reply-To: <D0FA0C3F-8DA8-4607-A0A6-F9AFAB3EC3CE@gmail.com>
On Mon, May 09, 2011 at 01:34:22AM -0700, David Lee wrote:
> > 4. Decentralized, you're a developer that publishes work via git. You
> > call the upstream maintainer "origin", so fetches are convenient
> > (and git does this for you at clone, after all). But pushing, even
> > though you probably always push to the same central, does not have
> > a convenient shorthand.
>
> By "push to the same central", I assume you mean "push to the same mirror of origin".
Yeah, sorry, that was supposed to be "central spot", but I think you got
the meaning.
> I think github is making option 4 the dominant use case. In fact, in
> our workplace we have a similar workflow set up, where we pull from a
> central origin, but push to individual mirrors from where commits are
> reviewed, tested, and merged unto origin.
Yeah, I think we will see more of that as decentralized workflows (and
the tools that support them) mature.
With respect to supporting an alternate default push destination, I'm
not sure what is the best change to make. If "origin" were simply the
default, I would say we should have a push.defaultRemote config that
lets you specify something else.
But it's not that simple. If you are on branch "foo", and you have
"branch.foo.remote" set in your config, then the value of that config
option becomes the default remote. Which makes some sense for pulling
(and there is the associated branch.*.merge config), but of course
pushing may not match.
But now we have precedence questions. If I have config like:
[push]
defaultRemote = my-mirror
[branch "foo"]
remote = origin
merge = refs/heads/master
which remote should be the default for "git push"? Obviously if I'm not
on "foo", it should be my-mirror. But if I am, should push.defaultRemote
take precedence? Should there also be a branch.*.pushRemote config that
takes precedence over branch.*.remote?
I have to admit that I have never found the branch.*.remote config to be
useful for any of my workflows, so I am not really sure how people use
it.
-Peff
next prev parent reply other threads:[~2011-05-09 11:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-07 8:10 Separate default remotes for pulling and pushing David Lee
2011-05-07 9:50 ` Sverre Rabbelier
2011-05-09 8:17 ` Jeff King
2011-05-09 8:34 ` David Lee
2011-05-09 11:10 ` Jeff King [this message]
2011-05-09 19:01 ` David Lee
2011-05-09 22:06 ` Jeff King
2011-05-09 16:45 ` Junio C Hamano
2011-05-09 22:04 ` Jeff King
2011-05-09 22:46 ` Junio C Hamano
2011-05-10 20:17 ` Jeff King
2011-05-10 12:47 ` Jay Soffian
2011-05-10 20:20 ` Jeff King
2011-05-10 21:12 ` Jay Soffian
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=20110509111019.GD9060@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=davidomundo@gmail.com \
--cc=git@vger.kernel.org \
--cc=srabbelier@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 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).