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? - 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? Thanks, Volodya
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.
- 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. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
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 12/04/2013 06:48 AM, Bjørn Roald wrote:
Can we clean up and get rid of the forks that we are done with?
According to https://help.github.com/articles/fork-a-repo you can delete your own forks, so I guess it is simple enough. -- Bjørn
On Wed, Dec 4, 2013 at 8:51 AM, Agustín K-ballo Bergé <kaballo86@hotmail.com> 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.
On Wed, Dec 4, 2013 at 12:55 AM, Andrey Semashev <andrey.semashev@gmail.com>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
On Wed, Dec 4, 2013 at 8:51 AM, Agustín K-ballo Bergé <kaballo86@hotmail.com> wrote: 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.
Yes, that's a well-know problem with pull requests. They can put a polished veneer over a totally bogus patch. Regardless of version control system and how pretty a package the patch comes in, a library maintainer needs to vet patches carefully. Is sufficient motivation provided? Are they accompanied by test cases? Do they include any required documentation changes? Will they work across all supported platforms? Is the code itself OK? Etc. Etc. Etc. --Beman
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.
2013/12/4 Agustín K-ballo Bergé <kaballo86@hotmail.com>:
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.
User accounts on GitHub work this way. The owner can add any number of collaborators. Organization accounts work differently [1]. Repositories of an organization account don't have a particular owner. Instead, repositories belongs to teams. Members of teams with admin privileges can add members to their team, but they than have admin privileges too. We need to discuss whether this is what we want. [1] https://help.github.com/articles/what-are-the-different-access-permissions
On Tue, Dec 3, 2013 at 11:44 PM, Vladimir Prus <ghost@cs.msu.su> 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?
I think the answer to both questions is that you do not have "Owner" permission. I was the Owner that handled your "build" permissions request, and I'm just now learning how the GitHub "Team" permissions system works. I need to verify that it is possible to give you "Owner" permission without also giving it to all the other team members. Please remember that several of us performing admin functions are totally new to GitHub organization level account management and it is going to take some time to come up to speed.
- 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. --Beman
On 4 December 2013 20:54, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Dec 3, 2013 at 11:44 PM, Vladimir Prus <ghost@cs.msu.su> 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
On 4 December 2013 20:54, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Dec 3, 2013 at 11:44 PM, Vladimir Prus <ghost@cs.msu.su> 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 <daniel@calamity.org.uk> 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 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. (And the things that Linus was objecting to in that link look like things fairly unique to the kernel and its development habits.)
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
participants (9)
-
Agustín K-ballo Bergé -
Andrey Semashev -
Beman Dawes -
Bjørn Roald -
Daniel James -
Daniel Pfeifer -
Gavin Lambert -
John Maddock -
Vladimir Prus