Mailinglist Archive: opensuse-buildservice (250 mails)

< Previous Next >
Re: [opensuse-buildservice] [PATCH] osc: add -c flag to check package out to current diretory
  • From: Jeff Mahoney <jeffm@xxxxxxxx>
  • Date: Wed, 22 Apr 2009 09:52:59 -0400
  • Message-id: <49EF213B.4050707@xxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greg Freemyer wrote:
On Wed, Apr 22, 2009 at 8:44 AM, Peter Pöml <poeml@xxxxxxx> wrote:
Am 16.04.2009 um 19:48 schrieb Brandon Philips:
<snip>
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
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >