Hi Peff, On Thu, 14 Nov 2019, Jeff King wrote: > On Wed, Nov 13, 2019 at 01:04:35PM +0100, Johannes Schindelin wrote: > > > > We talked a while ago about having GitGitGadget operate on git/git, > > > rather than on a separate mirror. That would automatically help at least > > > one class of PR-opener: people who want their patches to reach the list > > > but didn't realize they should be using gitgitgadget/git. > > > > > > I don't remember what the technical blockers are for getting that set > > > up, but it seems like a strictly nicer outcome than auto-closing their > > > PR. > > > > Okay, here are a couple of technical challenges, off the top of my head: > > [...] > > Not an easy, nor a small project, I am afraid. > > Yow. That's a lot more involved than I was hoping for. > > Thanks for writing it up. Some of the points raised were interesting. I > do think we'd want git/git (the repository) to remain read-only if > possible. I guess you're right. We should probably try to restrict the permissions as much as possible, not only deny write access to the repository. For example, one thing GitGitGadget does is to add these "Checks" to the commits of the PRs which contain links to the corresponding commits in gitster/git (if any). Those can actually not be removed, there is not even any API for that. So it would probably make sense to avoid that in git/git. This would mean that the git/git part of GitGitGadget does not install those commit mappings. I guess that's okay, they _are_ kinda hard to use. > If GitHub's permissions model is a limiting factor here, let me know > and I can try to bring it to the attention of the right people. I actually don't think that my use case fits any sane permission model ;-) After all, I want the GitHub App to _span_ repositories (even orgs), and that's not really the idea of Apps. After sleeping over it, I don't actually think that it is such a bad idea to add a second GitHub App with a more limited permission set. Ciao, Dscho
