Hi Jeff, Greg, Brandon, hi list, On Wed, Apr 22, 2009 at 09:49:15AM -0400, Jeff Mahoney wrote:

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.

Yes, that's what I had in mind. Although it's nice to be able to provide a change (patch) in a convenient way (convenient at least for people who are trained in git), that ultimately doesn't make a change go into mainline by itself. There needs to be someone who "takes" it. That's the same kind of barrier like giving someone commit access. Giving commit access is a bigger (single) step but it fits our development well. We don't need several levels of trust (or lots of branches). The fact that it took long to give Brandon write access ("direct push access") was not due to the used SCM, and it was not at all hindered by a complicated decision process in the way. In fact, it was all decided in a split second, however the act of granting the access was something that only one person could do (bottleneck) which didn't happen (for unrelated reasons). Giving direct push access to a git repository will always also require somebody to do "something", which can constitute just the same kind of bottleneck. The fact that git patches can be "pulled" is nice and neat, but we don't need that, if direct access is to be granted anyway (which is the development model which we use so far). Somebody else could of course have applied Bandons patch since long (or would have pulled it when we'd use git), but the problem was not that we don't have ways to get a change applied to mainline, the problem was to give direct access. Hence my initial statement (and I do maintain that viewpoint), that it doesn't help to switch to another SCM, when it comes to give someone a way to directly change mainline. Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development