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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Peff,

On Tue, 12 Mar 2019, Jeff King 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`.

I also designed GitGitGadget to tag iterations it sent, and to push those
tags to the public repository. I personally find it pretty frustrating
just *how hard* it is to go from a given mail in the mailing list archive
to a fully working local branch, even if that was exactly what the
original contributor had to begin with. With these tags (of the form
pr-103/slavicaDj/add-i-v5), that's not a problem.

Now, I was rather certain that Junio would *not* want that Git note in
https://github.com/git/git, let alone all those tags.

Yet for ease of implementation, GitGitGadget uses the very same fork where
the GitGitGadget PRs live to push those refs.

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).

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.

Ciao,
Dscho

P.S.: Fun fact: I came up with the name while discussing the idea of the
"UI" (using PR comments to send commands and get answers) with Stolee,
pretty much precisely a year ago, and when I tried to find a label for
what this thing that I have in mind is all about, it was "kind of a gadget
that works on git.git".

So yeah, I had https://github.com/git/git PRs in mind when I started, and
I only started the gitgitgadget/git fork in order to prove that it works,
and that it has benefits.

If it was not for my wonderfully supportive team, I would probably have
abandoned it after encountering so many pushbacks (`amlog` being actively
made useless for me, the unexpectedly negative reactions to GitGitGadget,
all the work being left to me, etc). But my outstanding teammates really
made a difference, and can now reap the benefits of having a system that
only requires a GitHub account to contribute to Git. As well as occasional
contributors, I might want to add, whose contributions we would have lost
if it was not for GitGitGadget.