On 12/04/2013 05:51 AM, Agustín K-ballo Bergé wrote:

On 04/12/2013 01:44 a.m., Vladimir Prus wrote:

...

Hi,

I have a couple of questions about the permission models that we use for git.

- To give somebody push access to the 'build' repository, I need to file an admin issue. Why can't I control access to the repository I maintain? In fact, why I can't even edit repository description?

+1 I believe library authors/maintainers should have admin access to their own repositories, and thus have direct control over the permissions granted to collaborators.

+1

...

- 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 won't scale), or I need to fork the repo, to the change, and submit a pull request, which is equally cumbersome. Was not Git supposed to simplify things?

True, that's the recommended procedure. Note however that you can edit the file "in-place" from github, and it will take care of the fork and pull request for you. All you need to do is edit the file on a web form.

That is nice, however I can't escape the feeling that the fork - pull request solution feels very heavy handed for many use-cases. That GitHub have a neat web interface solution that does the lifting does not change the weight of it. Can we clean up and get rid of the forks that we are done with? -- Bjørn

On Wed, Dec 4, 2013 at 8:51 AM, Agustín K-ballo Bergé wrote:

On 04/12/2013 01:44 a.m., Vladimir Prus 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 won't scale), or I need to fork the repo, to the change, and submit a pull request, which is equally cumbersome. Was not Git supposed to simplify things?

True, that's the recommended procedure. Note however that you can edit the file "in-place" from github, and it will take care of the fork and pull request for you. All you need to do is edit the file on a web form.

That has the drawback that you (the pull request submitter) don't verify that the change is valid. I already got hit by this once in my very short experience with github.

I have a couple of questions about the permission models that we use for git.

- To give somebody push access to the 'build' repository, I need to file an admin issue. Why can't I control access to the repository I maintain? In fact, why I can't even edit repository description?

+1 I believe library authors/maintainers should have admin access to their own repositories, and thus have direct control over the permissions granted to collaborators.

+1. Beman, if this is likely to be fixed/changed soon I'll hold off filing any more admin requests, and add additional folks to the Math and Multiprecision libs myself, otherwise it's back to filing admin requests I guess. Thanks, and my apologies for the small blizzard of requests you guys are getting, you're doing, and have done, great work with the conversion! John.

On 4 December 2013 20:54, Beman Dawes wrote:

...

On Tue, Dec 3, 2013 at 11:44 PM, Vladimir Prus 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 won't scale), or I need to fork the repo, to the change, and submit a pull request, which 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 of 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:

https://github.com/torvalds/linux/pull/17#issuecomment-5654674

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

On Thu, Dec 5, 2013 at 7:04 PM, Daniel James wrote: 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. --Beman PS: I'll be traveling until Monday, with very limited email contact.

On 09.12.2013 08:04, Gavin Lambert wrote:

On 6/12/2013 15:54, Quoth Beman Dawes:

...

...

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:

https://github.com/torvalds/linux/pull/17#issuecomment-5654674

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.

Speaking as one who has made several pull requests on GitHub (though admittedly only to a small number of projects), I can definitely attest to them being a process over time. (But that's what you'd expect, and want, usually.)

Each request has both a discussion thread and a branch, allowing the maintainer to test the code and recommend additional changes be made by the submitter (even if just to merge up to latest HEAD and resolve conflicts if it takes a while).

I've had some simple requests get merged almost immediately, and more complex ones take several months until the maintainer can find time to look at them properly. But the process was fairly smooth both ways.

Honestly, I still prefer gerrit model over github fork/pull-request model, where to publish a patch for review you just do, in your local git clone, something like: git push review And this creates a review request on the server. So, no need to bother with a work, or pull request. And then, if you wish to revise your patch, just run the same command again. And a reviewer can actually fetch your patch locally, for testing, whereas github instructions for same are long-winded. Effectively, gerrit creates a somewhat hidden branch you can use to collaborate on a patch in a rather direct way. There are some approaches for integrating github and gerrit, but I don't know how well they work. - Volodya