Re: GitGitGadget on github.com/git/git?, was Re: [RFC/PATCH] point pull requesters to Git Git Gadget

> Hi Peff,
>
> On Thu, 14 Mar 2019, Jeff King wrote:
>
>> On Thu, Mar 14, 2019 at 01:04:51PM +0100, Johannes Schindelin wrote:
>>
>> > > One thing that I think submitGit can do that GGG cannot (yet), is just
>> > > take PRs straight on git/git. If we're going to start recommending it,
>> > > then I think we'd probably want to configure that, since it's one less
>> > > confusing step for first-timers, who right now might have to go re-make
>> > > their PR on gitgitgadget/git.
>> >
>> > I just realized that I had not responded to that yet. It is not *quite*
>> > that easy, unfortunately.
>> >
>> > I did design GitGitGadget to have a state. For example, to avoid spamming
>> > the Git mailing list with bogus patch series, GitGitGadget maintains a
>> > list of GitHub user names for users allowed to send patch series. (I saw
>> > my share of bogus PRs in the Git for Windows fork, and had no desire to
>> > facilitate similar patch series on the list.) This information, together
>> > with information about the Message IDs to monitor, and about the PRs that
>> > are still open, are maintained in a JSON-formatted object that is stored
>> > in `refs/notes/gitgitgadget`.
>>
>> Ah, I wondered if there might be a catch like this. I do think it would
>> be nice to keep that ref out of git.git. We definitely would not want to
>> lose the features that depend on it, but it sounds like we could use a
>> separate metadata repository.
>
> How about... brace yourself... https://github.com/gitgitgadget/git?

> Seriously, I still think that the `refs/notes/gitgitgadget` note was a
> rather smart idea, and it was designed to allow for serving multiple
> repositories. You will note that the PR references in
> https://github.com/gitgitgadget/git/blob/1380f7ee9aaf/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
> are all full URLs, including the GitHub domain and the org. So if any
> contributor feels strongly enough to support, say, BitBucket or GitLab in
> GitGitGadget, the data structures support that (and I would gladly accept
> PRs for a change).
>
> Read: yes, we could totally extend GitGitGadget in a minimal fashion so
> that it supports PRs at https://github.com/git/git and stores the relevant
> metadata in http://github.com/gitgitgadget/git's `gitgitgadget` note,
> still.
>
>> > I could imagine that we keep pushing those refs to gitgitgadget/git,
>> > but now also allow for PRs on git/git to use GitGitGadget (we would
>> > have to install the GitHub App there, too, and I would have to change
>> > the code to allow that, and we would have to use a slightly different
>> > format for the tags generated from git/git PRs to avoid clashes with
>> > the gitgitgadget/git PRs, all of which is totally doable).
>>
>> I don't think connecting the GitHub App should be a big deal. Ideally it
>> would not even need write permission to the git/git repository, if it's
>> keeping metadata elsewhere (it would need to be able to write PR
>> comments, of course).
>
> Well, bummer. I cannot tell GitHub that it needs a certain permission on
> git/git vs another permission on gitgitgadget/git.
>
> I guess I'll have to be really diligent about the code base of
> GitGitGadget, then. Or maybe I'll use a second GitHub App that is only
> installed on gitgitgadget/git, as a hack.
>
>> It might not be a show-stopper if GitHub's permissions aren't
>> fine-grained enough to allow that, but not having repo write access
>> would be nice insurance against bugs in GitGitGadget writing where we
>> don't expect it to.
>
> Right. Hack it is.
>
>> > If this is truly something we ("we" as in "engaged Git developers")
>> > want, I can set aside some time to work on that. I had originally
>> > planned on exactly that, i.e. supporting PRs on git/git, but I got
>> > rather strong indications that GitGitGadget is hated by some (Duy, for
>> > example, was very vocal about refusing to even look at any of the
>> > GitGitGadget-sent patch series, let alone using the tool himself).
>> > While I think that this hate is undeserved, I cannot change other
>> > people's feelings, nor would I try, all I can do is to try not to make
>> > the situation worse.
>> >
>> > In short: before I spend serious time on extending GitGitGadget to
>> > handle git/git PRs, I want to be sure that I won't get backlash for
>> > that.
>>
>> IMHO, GitGitGadget is a useful tool to develop. It has some rough edges,
>> still, but I think the _idea_ is certainly a good one. Especially if the
>> dream of bi-directionality is ever fulfilled (though I am not exactly
>> holding my breath on that; I think it can get very tricky). But even
>> without that, I think it's useful to have something like it (or
>> submitGit) available for some contributors.
>
> Agreed.
>
>> In general, I have not minded the use of GGG on the list lately by you
>> or Stolee. I do complain about the rough edges (timestamps, sender-cc on
>> the cover letter, etc), but even as it stands now I am not hating it as
>> a reviewer. If you are happy with it on the sending side, and especially
>> if you want to smooth some of those rough edges, then I do not have a
>> problem myself with its continued use.
>
> Well, Peff, if I had to rank the Git mailing list regulars by "niceness",
> you would be on top. I never doubted that you'd be okay with it.
>
> Junio has been quite a bit more critical of it. And Duy really made a
> stink of it. But yeah, while I really did not feel any love for
> GitGitGadget, I also did not hear more than two voices speaking out
> against at least the current state of GitGitGadget.
>
> I'll give others time to chime in before I decide whether I should take
> GitGitGadget into the direction of git/git. (Because, remember, it is not
> quite "free", it takes a lot of time out of my schedule.)
>
> For the time being, I'll of course continue GitGitGadget myself, primarily
> because it addresses precisely all of my needs. Which makes sense, because
> those who develop the software always get the most out of it. It's the way
> it goes.