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.
