-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg Freemyer wrote:
On Wed, Apr 22, 2009 at 8:44 AM, Peter Pöml
wrote: Since git is distributed I could have made my patch commit to a private repo and you could have pushed my change into the "mainline" repo without giving me commit rights to the mainline repo. It would have saved the longish process of getting me commit rights. This is the part that I don't understand. How can an arbitrary person (in
Am 16.04.2009 um 19:48 schrieb Brandon Philips: <snip> this case, that would be you) push a change into the "mainline" repository? You would need to be authorized to do that, no? I can't imagine that a git repository would be set up in a way that anonymous users would have write permissions; it would sound dangerous for practical reasons, but I don't know much about git.
Peter
Peter,
I think Brandon slightly mis-worded it. Git is a pull based system, not a push based system.
Hi Greg - He misworded it here, but Git is both a push and a pull system. We use the push functionality to manage our kernel repository.
So he could have maintained a local git repository and created his patch, tested it etc. Then sent you a pull request. You would have the responsibility of deciding if it was safe to pull or not. That should take less time than deciding if Brandon should have full commit rights to the source repository.
It's also a step up in the trust relationships git allows you to foster. You can accept patches, accept pull requests, and ultimately allow direct push access if there is an agreed-upon "master" repository.
FYI: git was designed for by Linus himself for handling the thousands of patches a month that come his way through a hierarchy of maintainers / developers. He needed a highly scalable solution. A pull based system does not at first sound like a highly scalable solution, but it obviously is by the sheer fact that is handles the largest distributed development project around.
Linus has a set of maintainers that he trusts. When they send him a pull request, he basically does it automatically with no review on his part. If he gets one from someone outside of that team he has to decide if it should be allowed to come straight to him, or if it should have gone through one of the trusted subsystem maintainers. I assume he rarely, if ever, accepts a pull request that is not from his core set of maintainers.
It scales because he's made the workflow hierarchical. This is a good example of a project that is highly collaborative, but ultimately has one person in charge. Other collaborative projects are lead by a core team, who each have direct access to the repository. In reality, this is just convention since git doesn't have a built-in concept of a master repo. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAknvITsACgkQLPWxlyuTD7J3LgCggp7bH4lOTEAmGNvVK1uKq1Cr RtAAnjAASmRJUcQ8MJi+A2GuVgw5SvEE =yBwu -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org