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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html