On Fri, Jun 07, 2013 at 08:47:59AM -0700, Junio C Hamano wrote:
> When branch.$name.push mechanism is introduced and the user uses it,
> then "upstream", "simple", or any other setting for that matter
> would be ignored. With
> [branch "master"]
> remote = upstream
> merge = refs/heads/master
> pushremote = origin
> push = refs/heads/master
> it is clear that "git push" while on 'master' should push to origin
> to update its master branch.
Thanks for the detailed explanations, I think this would cover my use
case. Just for clarification, here are some more details on this use
case, which I think is becoming very popular among github users.
We have a "blessed" repository (upstream in my case) and only a few
people is able to push to it (let's call them maintainers). Every
developer, including the ones with push access, have to go through peer
reviewing and are not allowed to push their own commits to upstream. For
peer reviewing, each have it's own public fork, that other people can
review and merge/push if is good.
In this scheme, you always pull from the blessed repository and only
push to your personal fork, with the exceptions of the maintainers that
need to push from time to time other people pull requests.
My ideal would be to be able to just do 'git pull' to get the new stuff
and 'git push' to push to my fork. Since pushing to the blessed
repository is more "critical", is perfect that I need to explicitly push
to it with 'git push upstream master'.
Senior R&D Developer
sociomantic labs GmbH <http://www.sociomantic.com>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html