git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org, Roberto Tyley <roberto.tyley@gmail.com>
Subject: Re: GitGitGadget on github.com/git/git?, was Re: [RFC/PATCH] point pull requesters to Git Git Gadget
Date: Thu, 14 Mar 2019 23:30:20 -0400	[thread overview]
Message-ID: <20190315033020.GE28943@sigill.intra.peff.net> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1903141235390.41@tvgsbejvaqbjf.bet>

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.

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

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

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.

-Peff

  parent reply	other threads:[~2019-03-15  3:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-12 21:32 [RFC/PATCH] point pull requesters to Git Git Gadget Jeff King
2019-03-12 23:08 ` Roberto Tyley
2019-03-13 19:34   ` Jeff King
2019-03-13 20:50   ` Johannes Schindelin
2019-03-13  1:49 ` Junio C Hamano
2019-03-13 19:39   ` Jeff King
2019-03-13 20:18     ` Jeff King
2019-03-14 11:31       ` Johannes Schindelin
2019-03-15  3:19         ` Jeff King
2019-03-15 13:42           ` Johannes Schindelin
2019-03-15 18:43             ` Jeff King
2019-03-18  2:52       ` Junio C Hamano
2019-03-18 21:12         ` Jeff King
2019-03-18 21:48           ` Thomas Gummerer
2019-03-18 21:52             ` Jeff King
2019-03-19  0:30               ` Junio C Hamano
2019-03-18 22:25           ` Ævar Arnfjörð Bjarmason
2019-03-13 21:05     ` Johannes Schindelin
2019-03-13 22:17     ` Junio C Hamano
2019-03-13  2:07 ` Junio C Hamano
2019-03-13  2:18   ` Junio C Hamano
2019-03-13 19:39     ` Jeff King
2019-03-14 12:04 ` GitGitGadget on github.com/git/git?, was " Johannes Schindelin
2019-03-14 14:46   ` Duy Nguyen
2019-03-15  3:30   ` Jeff King [this message]
2019-03-15 14:51     ` Johannes Schindelin
2019-03-15 16:28       ` Ævar Arnfjörð Bjarmason
2019-03-15 18:41         ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190315033020.GE28943@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=roberto.tyley@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).