Hi Peff,

On Thu, 14 Nov 2019, Jeff King wrote:

On Wed, Nov 13, 2019 at 01:04:35PM +0100, Johannes Schindelin wrote:

quoted

quoted

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