On Fri, Mar 15 2019, Johannes Schindelin wrote: > 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? FWIW I'd love to see it on git/git for discoverability. From the rest of your E-Mail it sounds like you're working on that. So just a +1. If that doesn't work for whatever reason maybe we can amend git.git with this to point people to it: https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository We have one in .github/PULL_REQUEST_TEMPLATE.md, maybe along with *.txt docs we should amend that, unless of course real GGG on git/git is imminent... > 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. FWIW my temptations to use it stopped at https://public-inbox.org/git/nycvar.QRO.7.76.6.1810022234350.2034@xxxxxxxxxxxxxxxxx/ i.e. In-Reply-To support. I've also noticed that for 1/1 patches it sends a 0/1, I don't do that, and personally wouldn't want to (just add any comments below "---"). But I'm really happy it's there & useful to people, just not tempted to use it myself because I have a workflow I use already, and from observing it in action I couldn't losslessly move 100% of my submissions to it.
