Subject: Re: [boost] Git permissions model
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-12-05 21:54:31
On Thu, Dec 5, 2013 at 7:04 PM, Daniel James <daniel_at_[hidden]> wrote:
> On 4 December 2013 20:54, Beman Dawes <bdawes_at_[hidden]> wrote:
> > On Tue, Dec 3, 2013 at 11:44 PM, Vladimir Prus <ghost_at_[hidden]> wrote:
> >> - Suppose I find a random typo in library X. In SVN, I can just fix it
> >> within a minute.
> >> In Git, I would have to either ask for push access (which I think
> >> scale), or
> >> I need to fork the repo, to the change, and submit a pull request,
> >> is equally
> >> cumbersome. Was not Git supposed to simplify things?
> > I've had exactly the same thoughts. I'm guessing there is some third way
> > handling simple "drive-by" fixes, and we don't know what it is because of
> > unfamiliarity.
> > Other projects using git have almost certainly figured out an easy way to
> > handle "drive-by" fixes. We need to tap into that experience to find out
> > what works. In similar situations, a bit of googling around quickly turns
> > up blogs or stackoverflow solutions that are known to work.
> I think the Linux kernel uses git's built in pull request mechanism. I
> don't know anything about it, so I don't know if it would be
> appropriate for us. Most people do seem to prefer using github, and as
> many of our contributors are windows users they might be more
> comfortable using a web interface than the command line. Here's Linus
> Torvalds writing about it in his charming manner:
> He isn't the only one who doesn't like GitHub's (as distinguished from
git's) pull request mechanism. I read a blog about that a couple of days
ago, where the author talked about how submitting a fix to an open source
project was a process over time, not a single even. It has to start to with
submitter having some feeling for how the project handles maintenance,
testing, docs, etc. and progress through a dialog.
PS: I'll be traveling until Monday, with very limited email contact.