[RFC/PATCH] point pull requesters to Git Git Gadget

[RFC/PATCH] point pull requesters to Git Git Gadget

[Jeff King]

In the contributing guide and PR template seen by people who open pull
requests on GitHub, we mention the submitGit tool, which gives an
alternative to figuring out the mailing list. These days we also have
the similar Git Git Gadget tool, and we should make it clear that this
is also an option.

We could continue to mention _both_ tools, but it's probably better to
pick one in order to avoid overwhelming the user with choice. After all,
one of the purposes here is to reduce friction for first-time or
infrequent contributors. And there are a few reasons to prefer GGG:

  1. submitGit seems to still have a few rough edges. E.g., it doesn't
     munge timestamps to help threaded mail readers handled out-of-order
     delivery.

  2. Subjectively, GGG seems to be more commonly used on the list these
     days, especially by list regulars.

  3. GGG seems to be under more active development (likely related to
     point 2).

So let's actually swap out submitGit for GGG. While we're there, let's
put another link to the GGG page in the PR template, because that's
where users who are learning about it for the first time will want to go
to read more.

Signed-off-by: Jeff King <peff@peff.net>
---
I feel a little bad sending this, because I really value the work that
Roberto has done on submitGit. So just dropping it feels a bit
dismissive. But for the reasons above, it seems like GGG is going to be
the path forward, and it doesn't really make much sense to have two
competing systems unless they have really different feature-sets or
approaches (which I don't think is the case).

So I thought I'd mark this RFC and see what people thought. :)

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.

 .github/CONTRIBUTING.md          | 2 +-
 .github/PULL_REQUEST_TEMPLATE.md | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
index 64e605a02b..7e6df9e429 100644
--- a/.github/CONTRIBUTING.md
+++ b/.github/CONTRIBUTING.md
@@ -5,7 +5,7 @@ Git community does not use github.com for their contributions. Instead, we use
 a mailing list (git@vger.kernel.org) for code submissions, code
 reviews, and bug reports.
 
-Nevertheless, you can use [submitGit](http://submitgit.herokuapp.com/) to
+Nevertheless, you can use [Git Git Gadget](https://gitgitgadget.github.io/) to
 conveniently send your Pull Requests commits to our mailing list.
 
 Please read ["A note from the maintainer"](https://git.kernel.org/pub/scm/git/git.git/plain/MaintNotes?h=todo)
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index adba13e5ba..85911a44e2 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -1,7 +1,7 @@
 Thanks for taking the time to contribute to Git! Please be advised that the
 Git community does not use github.com for their contributions. Instead, we use
 a mailing list (git@vger.kernel.org) for code submissions, code reviews, and
-bug reports. Nevertheless, you can use submitGit to conveniently send your Pull
-Requests commits to our mailing list.
+bug reports. Nevertheless, you can use Git Git Gadget (https://gitgitgadget.github.io/)
+to conveniently send your Pull Requests commits to our mailing list.
 
 Please read the "guidelines for contributing" linked above!
-- 
2.21.0.539.gcf54785f87

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Roberto Tyley]

On Tue, 12 Mar 2019 at 21:34, Jeff King <peff@peff.net> wrote:
...
> We could continue to mention _both_ tools, but it's probably better to
> pick one in order to avoid overwhelming the user with choice. After all,
> one of the purposes here is to reduce friction for first-time or
> infrequent contributors. And there are a few reasons to prefer GGG:

That's fair enough - I haven't committed to submitGit for 2 years
(it's continued to work without incident for most of that time I
think!). I would be prepared to spend more time on it if it was
important to people - or, heavens forfend, I could be paid to do so :)
 - but I have a lot of projects (not just software ones!) and
submitGit kind of fell to the bottom of the pile. I wasn't aware of
https://gitgitgadget.github.io/ but it looks good!

>   1. submitGit seems to still have a few rough edges. E.g., it doesn't
>      munge timestamps to help threaded mail readers handled out-of-order
>      delivery.

Yup, very true.

>   2. Subjectively, GGG seems to be more commonly used on the list these
>      days, especially by list regulars.

That's probably true too, though my interest with submitGit was more
driven by helping early/first-time contributors than regulars. Though
I'm sure GGG works well, in an ideal world it would be interesting to
get a perspective from a cohort of those kind of users about what kind
of flow works best for them - although, as I haven't been following
development, maybe this has already been done?

>   3. GGG seems to be under more active development (likely related to
>      point 2).

Definitely true!

> I feel a little bad sending this, because I really value the work that
> Roberto has done on submitGit. So just dropping it feels a bit
> dismissive.

Oh, you're very kind, that's ok! Very glad submitGit could help for a
while, sounds like it was a good proof that GitHub could become part
of the contribution process.

Roberto

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Jeff King]

On Tue, Mar 12, 2019 at 11:08:00PM +0000, Roberto Tyley wrote:

> On Tue, 12 Mar 2019 at 21:34, Jeff King <peff@peff.net> wrote:
> ...
> > We could continue to mention _both_ tools, but it's probably better to
> > pick one in order to avoid overwhelming the user with choice. After all,
> > one of the purposes here is to reduce friction for first-time or
> > infrequent contributors. And there are a few reasons to prefer GGG:
> 
> That's fair enough - I haven't committed to submitGit for 2 years
> (it's continued to work without incident for most of that time I
> think!).

Yeah, it has been working fine as far as I know. I was a little curious
about how often (and about my impression that GGG was replacing it), so
I did some quick mining of the list archive. Here are numbers of
messages each month (from the last ~100k messages) mentioning Amazon SES
(presumably submitGit) or GitGitGadget in the message-id. I omitted
months with no entries for either, so there are some gaps:

  ses ggg year-mo
  --- --- -------
    7   0 2015-07
    2   0 2015-08
    3   0 2015-09
    1   0 2015-11
    2   0 2016-01
    3   0 2016-02
   34   0 2016-03
   27   0 2016-04
    2   0 2016-05
    6   0 2016-06
   26   0 2016-07
   54   0 2016-08
    3   0 2016-09
   29   0 2016-10
    3   0 2016-12
    4   0 2017-01
    7   0 2017-03
    5   0 2017-04
    3   0 2017-05
   23   0 2017-06
    9   0 2017-07
   14   0 2017-09
    6   0 2017-10
    8   0 2017-11
    8   0 2017-12
   38   0 2018-01
   86   0 2018-02
   49   0 2018-03
    9   0 2018-04
    1   0 2018-05
    3   4 2018-06
    0  86 2018-07
   13 105 2018-08
    0  65 2018-09
   14 149 2018-10
    7 131 2018-11
    1  46 2018-12
   14  96 2019-01
   16 149 2019-02
    0  44 2019-03

That measures pure patches, so they tend to cluster as there are often
several patches in a series. Poking manually at the ses hits, submitGit
seems to have been often used by GSoC and Outreachy applicants and
interns.

I don't know if any of this really supports or refutes my earlier commit
message, but I just thought it was kind of neat to see the numbers, so I
thought I'd share.

> >   2. Subjectively, GGG seems to be more commonly used on the list these
> >      days, especially by list regulars.
> 
> That's probably true too, though my interest with submitGit was more
> driven by helping early/first-time contributors than regulars. Though
> I'm sure GGG works well, in an ideal world it would be interesting to
> get a perspective from a cohort of those kind of users about what kind
> of flow works best for them - although, as I haven't been following
> development, maybe this has already been done?

I think the flow is quite similar, and GGG is definitely geared at
helping infrequent contributors, too. Dscho might have more thoughts on
this.

The biggest friction is marking a user as allowed to send. I think in
submitGit you have to "OK" the submitGit app sending on your behalf.  In
GGG, somebody who already has been OK'd has to OK you with a comment in
the PR (after which you're approved for future PRs, too). It's possible
the approval could slow things down, but I think as long as users of the
tool are fairly prompt about approving non-spam PRs, it wouldn't be a
big deal.

> > I feel a little bad sending this, because I really value the work that
> > Roberto has done on submitGit. So just dropping it feels a bit
> > dismissive.
> 
> Oh, you're very kind, that's ok! Very glad submitGit could help for a
> while, sounds like it was a good proof that GitHub could become part
> of the contribution process.

Yes, I think it definitely was.

-Peff

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Johannes Schindelin]

Hi Roberto,

On Tue, 12 Mar 2019, Roberto Tyley wrote:

> On Tue, 12 Mar 2019 at 21:34, Jeff King <peff@peff.net> wrote:
> 
> > I feel a little bad sending this, because I really value the work that
> > Roberto has done on submitGit. So just dropping it feels a bit
> > dismissive.
> 
> Oh, you're very kind, that's ok! Very glad submitGit could help for a
> while, sounds like it was a good proof that GitHub could become part of
> the contribution process.

TBH I also felt quite bad for starting GitGitGadget rather than extending
submitGit. It's just that I faced too many obstacles with that:

- submitGit is stateless. I have *no* way of automatically including a
  range-diff.

- I remember that there were rather huge concerns about giving Amazon the
  keys to your email. This is so intricate a part of submitGit's design
  (even if you would change it to use another service to send mails in
  your name, you would still have to trust *some* service with your
  credentials).

- One of the things I *really* wanted was to have the tool mirror the
  replies on the mailing list back to the PR. Since submitGit does not
  *really* integrate with the GitHub interface (it might read some
  information, but it won't interact with the user there, opting instead
  on its own web interface), that was not something I could see submitGit
  to learn.

- Since submitGit does not write any state, there was no way to persist
  previous iterations in the form of the tags that GitGitGadget publishes.

- Finally, I never hid my concern about the choice of language (Scala
  might be a nice language to learn, even for me, some day, but trying
  to force people like me to learn a language that they did not plan on
  learning is probably a bad idea). I probably was too vocal about this,
  at times. And I still feel very strongly about this. Choosing a language
  that many developers of the target audience do *not* speak already is
  (in my mind) putting an unnecessary hurdle in front of contributors.

Regarding Scala: Granted, with Typescript rather than Javascript, I chose
another not-quite-mainstream language. But Scale is not even mentioned in
https://www.benfrederickson.com/ranking-programming-languages-by-github-users/
while Typescript is definitely an "up-and-coming language".

Also, I always wanted to learn how to write web applications, and this was
a perfect excuse to do so.

Nevermind that I had to convert this to a serverless part (an Azure
Function) with a user-visible backend (an Azure Pipeline that updates the
PR Check on GitHub and makes it easy to review the log, just in case
anything failed during the mail sending process). Due to the environment
(see below) this conversion was relatively painless, and you have *no*
idea how pleased I am that *nobody* realized that GitGitGadget underwent
such a rather dramatic architecture change. I essentially replaced the
engine of a Nascar machine with a differently-sized one, while the race
was still on.

In addition, I wanted to know what all this Typescript hype was all about,
and I was surprised just how many bugs were caught in my original
mail-patch-series.sh [*1*] that I converted to Javascript and then to
Typescript, by the mere fact of converting to Typescript. I also have to
admit that it felt quite pleasant to be able to use object-oriented
scripting, with an infrastructure of dependencies at your fingertips
(npm), and almost pain-free, portable, fast, intuitive unit testing
(jest).

So I am thankful for submitGit, and at the same time I still feel that it
was necessary to pit GitGitGadget against it. Almost as if (from my
perspective) the purpose of submitGit was to prod me into starting
GitGitGadget, to show what is possible.

Ciao,
Dscho

Footnote *1*: I originally used a shell script called
`mail-patch-series.sh` to submit my patch series, and later even published
it at https://github.com/dscho/mail-patch-series in the hopes that it
would benefit others (and that I'd get PRs to improve it). I learned,
however, that nobody wants to use anybody else's shell script to submit
their patch series, just like I found e.g. Lars Schneider's automatic
reviewer Cc:ing too broad, others did not like my choices like storing the
cover letter in the branch description (which is by definition not
pushable).

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> infrequent contributors. And there are a few reasons to prefer GGG:
>
>   1. submitGit seems to still have a few rough edges. E.g., it doesn't
>      munge timestamps to help threaded mail readers handled out-of-order
>      delivery.

Hmph, I had an impression that the recent "why aren't these sorted"
topics were via GGG, not submitGit, though.


>   2. Subjectively, GGG seems to be more commonly used on the list these
>      days, especially by list regulars.
>
>   3. GGG seems to be under more active development (likely related to
>      point 2).
>
> So let's actually swap out submitGit for GGG. While we're there, let's
> put another link to the GGG page in the PR template, because that's
> where users who are learning about it for the first time will want to go
> to read more.

Yeah, I see Roberto agrees with the direction, and I do too.

Thanks, Roberto for submitGit that served us well, Dscho for GGG
that will serve us better, and Peff for updating this ;-)

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Jeff King]

On Wed, Mar 13, 2019 at 10:49:22AM +0900, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > infrequent contributors. And there are a few reasons to prefer GGG:
> >
> >   1. submitGit seems to still have a few rough edges. E.g., it doesn't
> >      munge timestamps to help threaded mail readers handled out-of-order
> >      delivery.
> 
> Hmph, I had an impression that the recent "why aren't these sorted"
> topics were via GGG, not submitGit, though.

We did have one case a few months ago, but I think it was since fixed.
Whereas it cannot be fixed for submitGit without major re-architecting,
because the mails go out through Amazon SES, which writes its own
timestamp.

I could be wrong about GGG being fixed though. I haven't noticed the
problem lately, but we definitely had a submitGit-related one a few
weeks ago.

-Peff

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Jeff King]

On Wed, Mar 13, 2019 at 03:39:09PM -0400, Jeff King wrote:

> On Wed, Mar 13, 2019 at 10:49:22AM +0900, Junio C Hamano wrote:
> 
> > Jeff King <peff@peff.net> writes:
> > 
> > > infrequent contributors. And there are a few reasons to prefer GGG:
> > >
> > >   1. submitGit seems to still have a few rough edges. E.g., it doesn't
> > >      munge timestamps to help threaded mail readers handled out-of-order
> > >      delivery.
> > 
> > Hmph, I had an impression that the recent "why aren't these sorted"
> > topics were via GGG, not submitGit, though.
> 
> We did have one case a few months ago, but I think it was since fixed.
> Whereas it cannot be fixed for submitGit without major re-architecting,
> because the mails go out through Amazon SES, which writes its own
> timestamp.
> 
> I could be wrong about GGG being fixed though. I haven't noticed the
> problem lately, but we definitely had a submitGit-related one a few
> weeks ago.

Hmm. I guess it is still an issue in GGG. This thread has identical
timestamps on patches 1 and 2 (and my server received them out of order
by 2 seconds, so mutt orders them wrong):

  https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/

I do still think GGG has a more feasible path forward on this particular
bug, though.

-Peff

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Johannes Schindelin]

Hi Peff,

On Wed, 13 Mar 2019, Jeff King wrote:

> On Wed, Mar 13, 2019 at 03:39:09PM -0400, Jeff King wrote:
> 
> > On Wed, Mar 13, 2019 at 10:49:22AM +0900, Junio C Hamano wrote:
> > 
> > > Jeff King <peff@peff.net> writes:
> > > 
> > > > infrequent contributors. And there are a few reasons to prefer GGG:
> > > >
> > > >   1. submitGit seems to still have a few rough edges. E.g., it doesn't
> > > >      munge timestamps to help threaded mail readers handled out-of-order
> > > >      delivery.
> > > 
> > > Hmph, I had an impression that the recent "why aren't these sorted"
> > > topics were via GGG, not submitGit, though.
> > 
> > We did have one case a few months ago, but I think it was since fixed.
> > Whereas it cannot be fixed for submitGit without major re-architecting,
> > because the mails go out through Amazon SES, which writes its own
> > timestamp.
> > 
> > I could be wrong about GGG being fixed though. I haven't noticed the
> > problem lately, but we definitely had a submitGit-related one a few
> > weeks ago.
> 
> Hmm. I guess it is still an issue in GGG. This thread has identical
> timestamps on patches 1 and 2 (and my server received them out of order
> by 2 seconds, so mutt orders them wrong):
> 
>   https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/
> 
> I do still think GGG has a more feasible path forward on this particular
> bug, though.

Indeed. And it is a bug^Wfeature of GMail, I guess, that it knows better
and ignores the Date: header of the mbox fed to it.

The only workaround I can think of is to introduce ugly one-second-sleeps.
I will do that if it proves necessary, but I do have a problem right now
because my only GitGitGadget reviewer (Stolee) is kinda busy with other
things for the time being.

Ciao,
Dscho

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Jeff King]

On Thu, Mar 14, 2019 at 12:31:21PM +0100, Johannes Schindelin wrote:

> > Hmm. I guess it is still an issue in GGG. This thread has identical
> > timestamps on patches 1 and 2 (and my server received them out of order
> > by 2 seconds, so mutt orders them wrong):
> > 
> >   https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/
> > 
> > I do still think GGG has a more feasible path forward on this particular
> > bug, though.
> 
> Indeed. And it is a bug^Wfeature of GMail, I guess, that it knows better
> and ignores the Date: header of the mbox fed to it.

Heh. So it in fact has the identical problem that submitGit and SES
have. :)

> The only workaround I can think of is to introduce ugly one-second-sleeps.
> I will do that if it proves necessary, but I do have a problem right now
> because my only GitGitGadget reviewer (Stolee) is kinda busy with other
> things for the time being.

I suspect that may be the ultimate solution. Which isn't fantastic, but
at the same time, I doubt anybody would really notice that much. There
are typically delays of seconds to minutes already in delivering email.
Unless somebody has a 200 patch series, but maybe then it is kinder to the
receivers to let it trickle in. ;)

-Peff

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Johannes Schindelin]

Hi Peff,

On Thu, 14 Mar 2019, Jeff King wrote:

> On Thu, Mar 14, 2019 at 12:31:21PM +0100, Johannes Schindelin wrote:
> 
> > > Hmm. I guess it is still an issue in GGG. This thread has identical
> > > timestamps on patches 1 and 2 (and my server received them out of order
> > > by 2 seconds, so mutt orders them wrong):
> > > 
> > >   https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/
> > > 
> > > I do still think GGG has a more feasible path forward on this particular
> > > bug, though.
> > 
> > Indeed. And it is a bug^Wfeature of GMail, I guess, that it knows better
> > and ignores the Date: header of the mbox fed to it.
> 
> Heh. So it in fact has the identical problem that submitGit and SES
> have. :)
> 
> > The only workaround I can think of is to introduce ugly one-second-sleeps.
> > I will do that if it proves necessary, but I do have a problem right now
> > because my only GitGitGadget reviewer (Stolee) is kinda busy with other
> > things for the time being.
> 
> I suspect that may be the ultimate solution. Which isn't fantastic, but
> at the same time, I doubt anybody would really notice that much.

Fine, I'll put that on my backlog:
https://github.com/gitgitgadget/gitgitgadget/issues/81

> There are typically delays of seconds to minutes already in delivering
> email. Unless somebody has a 200 patch series, but maybe then it is
> kinder to the receivers to let it trickle in. ;)

Indeed. And you remind me: I wanted to disallow annoyingly large patch
series: https://github.com/gitgitgadget/gitgitgadget/issues/82

Another thing that I always dreamed of having: GitGitGadget could
automatically warn about commit messages that are incomplete, that
disagree with our preferred format, that contain typos or offensive
language.

Likewise, I had this idea that once we had some robust Clang format
definition, GitGitGadget could verify that the patches conform to what we
want, and automatically generate fixed branches if not.

Basically, all the automation I can get, to relieve humans from tasks that
machines can do.

Children can have dreams, can't they ;-)

Ciao,
Dscho

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Jeff King]

On Fri, Mar 15, 2019 at 02:42:42PM +0100, Johannes Schindelin wrote:

> Another thing that I always dreamed of having: GitGitGadget could
> automatically warn about commit messages that are incomplete, that
> disagree with our preferred format, that contain typos or offensive
> language.
> 
> Likewise, I had this idea that once we had some robust Clang format
> definition, GitGitGadget could verify that the patches conform to what we
> want, and automatically generate fixed branches if not.
> 
> Basically, all the automation I can get, to relieve humans from tasks that
> machines can do.
> 
> Children can have dreams, can't they ;-)

I like all of those dreams. :)

I think the "checks" could all just be another form of CI. I think there
may be some tricks with automatic rewriting, but it might be possible to
do it in the form of GitHub "suggestions", which a human could then
click "OK" to a bunch of them. I guess it would be overwhelming if you
really diverged style-wise and the diff is large.

I don't think GitHub has any support for changing commit messages,
though, short of your tool force-pushing.

-Peff

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Hmm. I guess it is still an issue in GGG. This thread has identical
> timestamps on patches 1 and 2 (and my server received them out of order
> by 2 seconds, so mutt orders them wrong):
>
>   https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/
>
> I do still think GGG has a more feasible path forward on this particular
> bug, though.

If the MSA is rewriting the timestamp (but why?  Is the original
date "Wed, 13 Mar 2019 19:20:12 GMT" malformed or perhaps in the
future or something?), then there isn't much the sending program
can---'git send-email' would suffer from the same symptom.

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Jeff King]

On Mon, Mar 18, 2019 at 11:52:54AM +0900, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > Hmm. I guess it is still an issue in GGG. This thread has identical
> > timestamps on patches 1 and 2 (and my server received them out of order
> > by 2 seconds, so mutt orders them wrong):
> >
> >   https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/
> >
> > I do still think GGG has a more feasible path forward on this particular
> > bug, though.
> 
> If the MSA is rewriting the timestamp (but why?  Is the original
> date "Wed, 13 Mar 2019 19:20:12 GMT" malformed or perhaps in the
> future or something?), then there isn't much the sending program
> can---'git send-email' would suffer from the same symptom.

I think this statement from me is mid-way through my discovery of the
actual issue. Yes, if the mail server is rewriting, the best we can do
is put in an artificial sleep.

It looks like GitGitGadget just uses normal SMTP to submit the messages.
I wonder if normal people using gmail as their SMTP server for
send-email also suffer from this. I've not ever noticed it, but I
don't know how common that setup is.

-Peff

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Thomas Gummerer]

On 03/18, Jeff King wrote:
> On Mon, Mar 18, 2019 at 11:52:54AM +0900, Junio C Hamano wrote:
> 
> > Jeff King <peff@peff.net> writes:
> > 
> > > Hmm. I guess it is still an issue in GGG. This thread has identical
> > > timestamps on patches 1 and 2 (and my server received them out of order
> > > by 2 seconds, so mutt orders them wrong):
> > >
> > >   https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/
> > >
> > > I do still think GGG has a more feasible path forward on this particular
> > > bug, though.
> > 
> > If the MSA is rewriting the timestamp (but why?  Is the original
> > date "Wed, 13 Mar 2019 19:20:12 GMT" malformed or perhaps in the
> > future or something?), then there isn't much the sending program
> > can---'git send-email' would suffer from the same symptom.
> 
> I think this statement from me is mid-way through my discovery of the
> actual issue. Yes, if the mail server is rewriting, the best we can do
> is put in an artificial sleep.
> 
> It looks like GitGitGadget just uses normal SMTP to submit the messages.
> I wonder if normal people using gmail as their SMTP server for
> send-email also suffer from this. I've not ever noticed it, but I
> don't know how common that setup is.

I am using gmail as my SMTP server with 'git send-email', and it
doesn't look like gmail is rewriting anything there, see [*1*] for
example.  The date header looks like this:

    Date: Mon, 25 Feb 2019 23:16:04 +0000

Note the +0000 there, compared to the GMT that GitGitGadget uses.
Looking at RFC2822, that's the new version of specifying the timezone,
while GMT is only defined in the obsolete time and date section.  I
guess gmail might just not like that anymore and rewrite it.

So fixing this might not be that hard, and might not involve sleeping
while sending the patch series at all.  Changing how the date is
calculated in [*2*] might be all that's needed.

*1*: https://public-inbox.org/git/20190225231631.30507-1-t.gummerer@gmail.com/raw
*2*: https://github.com/gitgitgadget/gitgitgadget/blob/c37d58cc1581b479892a1f7d29bd16e261676c7d/lib/patch-series.ts#L427

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Jeff King]

On Mon, Mar 18, 2019 at 09:48:42PM +0000, Thomas Gummerer wrote:

> > It looks like GitGitGadget just uses normal SMTP to submit the messages.
> > I wonder if normal people using gmail as their SMTP server for
> > send-email also suffer from this. I've not ever noticed it, but I
> > don't know how common that setup is.
> 
> I am using gmail as my SMTP server with 'git send-email', and it
> doesn't look like gmail is rewriting anything there, see [*1*] for
> example.  The date header looks like this:
> 
>     Date: Mon, 25 Feb 2019 23:16:04 +0000
> 
> Note the +0000 there, compared to the GMT that GitGitGadget uses.
> Looking at RFC2822, that's the new version of specifying the timezone,
> while GMT is only defined in the obsolete time and date section.  I
> guess gmail might just not like that anymore and rewrite it.
> 
> So fixing this might not be that hard, and might not involve sleeping
> while sending the patch series at all.  Changing how the date is
> calculated in [*2*] might be all that's needed.

Yes, if it really is as simple as just "gmail doesn't like our date
format, so it rewrites the header", that would be wonderful. Thanks for
an extra data point.

-Peff

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Mon, Mar 18, 2019 at 09:48:42PM +0000, Thomas Gummerer wrote:
>
>> > It looks like GitGitGadget just uses normal SMTP to submit the messages.
>> > I wonder if normal people using gmail as their SMTP server for
>> > send-email also suffer from this. I've not ever noticed it, but I
>> > don't know how common that setup is.
>> 
>> I am using gmail as my SMTP server with 'git send-email', and it
>> doesn't look like gmail is rewriting anything there, see [*1*] for
>> example.  The date header looks like this:
>> 
>>     Date: Mon, 25 Feb 2019 23:16:04 +0000
>> 
>> Note the +0000 there, compared to the GMT that GitGitGadget uses.
>> Looking at RFC2822, that's the new version of specifying the timezone,
>> while GMT is only defined in the obsolete time and date section.  I
>> guess gmail might just not like that anymore and rewrite it.
>> 
>> So fixing this might not be that hard, and might not involve sleeping
>> while sending the patch series at all.  Changing how the date is
>> calculated in [*2*] might be all that's needed.
>
> Yes, if it really is as simple as just "gmail doesn't like our date
> format, so it rewrites the header", that would be wonderful. Thanks for
> an extra data point.

I use send-email through SMTP MSA at either gmail or pobox depending
on the phase of the moon, and never noticed an issue with the
timestamp we generate.  But I noticed the "GMT" string in the
"original-date" trail in the problem message, which I didn't think
was an timestamp we would generate but somebody else might, and that
was why I quoted it in my message.  It is good that Thomas noticed
it, came up with a conjecture and a pointer to a possible fix ;-)

Thanks, all.

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Ævar Arnfjörð Bjarmason]

On Mon, Mar 18 2019, Jeff King wrote:

> On Mon, Mar 18, 2019 at 11:52:54AM +0900, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > Hmm. I guess it is still an issue in GGG. This thread has identical
>> > timestamps on patches 1 and 2 (and my server received them out of order
>> > by 2 seconds, so mutt orders them wrong):
>> >
>> >   https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/
>> >
>> > I do still think GGG has a more feasible path forward on this particular
>> > bug, though.
>>
>> If the MSA is rewriting the timestamp (but why?  Is the original
>> date "Wed, 13 Mar 2019 19:20:12 GMT" malformed or perhaps in the
>> future or something?), then there isn't much the sending program
>> can---'git send-email' would suffer from the same symptom.
>
> I think this statement from me is mid-way through my discovery of the
> actual issue. Yes, if the mail server is rewriting, the best we can do
> is put in an artificial sleep.
>
> It looks like GitGitGadget just uses normal SMTP to submit the messages.
> I wonder if normal people using gmail as their SMTP server for
> send-email also suffer from this. I've not ever noticed it, but I
> don't know how common that setup is.

It's the got-to setup for those of us using gmail & send-email. In
git-ml.git:

    $ git ls-files | wc -l
    371333
    $ git grep -l '^\s+by smtp.gmail.com with ESMTPSA id ' | wc -l
    35326

Roughly 1/2 of those are patches:

    $ git grep --no-line-number -h -C30 '^\s+by smtp.gmail.com with ESMTPSA id ' |grep "^Subject: \[" | wc -l
    14567

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Johannes Schindelin]

Hi,

On Wed, 13 Mar 2019, Jeff King wrote:

> On Wed, Mar 13, 2019 at 10:49:22AM +0900, Junio C Hamano wrote:
> 
> > Jeff King <peff@peff.net> writes:
> > 
> > > infrequent contributors. And there are a few reasons to prefer GGG:
> > >
> > >   1. submitGit seems to still have a few rough edges. E.g., it doesn't
> > >      munge timestamps to help threaded mail readers handled out-of-order
> > >      delivery.
> > 
> > Hmph, I had an impression that the recent "why aren't these sorted"
> > topics were via GGG, not submitGit, though.

Hmph. I thought these were sorted out by
https://github.com/gitgitgadget/gitgitgadget/pull/23...

Junio, if you are referring to your complaint in
https://public-inbox.org/git/xmqqftt83bt9.fsf@gitster-ct.c.googlers.com/,
I just had a look, and the dates of JeffH's 00/14, 01/14 and 02/14 were,
respectively,

Date:   Tue, 22 Jan 2019 13:22:12 -0800 (PST)
Date:   Tue, 22 Jan 2019 13:22:12 -0800 (PST)
and
Date:   Tue, 22 Jan 2019 13:22:14 -0800 (PST)

Not quite what PR #23 tried to achieve. So where does this problem come
from? A little further digging reveals another, quite revealing header:

X-Google-Original-Date: Tue, 22 Jan 2019 21:21:57 GMT
X-Google-Original-Date: Tue, 22 Jan 2019 21:21:58 GMT
and
X-Google-Original-Date: Tue, 22 Jan 2019 21:21:59 GMT

which makes a ton more sense because GitGitGadget would not ever use -0800
as generic timezone.

(to see for yourself, just direct your browser to
https://public-inbox.org/git/pull.108.git.gitgitgadget@gmail.com/raw
https://public-inbox.org/git/1a90de9dab0dd836e54fee9e08ab9e2284e1027a.1548192131.git.gitgitgadget@gmail.com/raw
and
https://public-inbox.org/git/4aaf4834bfa9f2169e2c00f7cdc6c75281567c15.1548192131.git.gitgitgadget@gmail.com/raw)

So the *real* problem is that your GMail developer colleagues, Junio,
decide that GitGitGadget's Date: header is not good enough, and override
it by a less useful version.

:-)

> We did have one case a few months ago, but I think it was since fixed.
> Whereas it cannot be fixed for submitGit without major re-architecting,
> because the mails go out through Amazon SES, which writes its own
> timestamp.
> 
> I could be wrong about GGG being fixed though. I haven't noticed the
> problem lately, but we definitely had a submitGit-related one a few
> weeks ago.

Maybe you use two different versions of mutt?

*ducks* ;-)

I come more and more to the conclusion that you can use whatever mail
client to read the Git mailing list, as long as it is mutt. Which leaves
me behind, as an Alpine (and occasional Thunderbird and Roundcube Mail)
user...

Ciao,
Dscho

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Mar 13, 2019 at 10:49:22AM +0900, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > infrequent contributors. And there are a few reasons to prefer GGG:
>> >
>> >   1. submitGit seems to still have a few rough edges. E.g., it doesn't
>> >      munge timestamps to help threaded mail readers handled out-of-order
>> >      delivery.
>> 
>> Hmph, I had an impression that the recent "why aren't these sorted"
>> topics were via GGG, not submitGit, though.
>
> We did have one case a few months ago, but I think it was since fixed.
>
> Whereas it cannot be fixed for submitGit without major re-architecting,
> because the mails go out through Amazon SES, which writes its own
> timestamp.
>
> I could be wrong about GGG being fixed though. I haven't noticed the
> problem lately, but we definitely had a submitGit-related one a few
> weeks ago.

Yeah, I was confused; <xmqqtvgk4urv.fsf@gitster-ct.c.googlers.com>
was about submitGit, but somehow I thought the sender switched to,
and the out-of-order thread was sent via, GGG.  My mistake.

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> -Nevertheless, you can use [submitGit](http://submitgit.herokuapp.com/) to
> +Nevertheless, you can use [Git Git Gadget](https://gitgitgadget.github.io/) to

The pointed-at page calls the tool a single word with three capital
Gs without SP in it.  We should match it here and in the other
document.

>  conveniently send your Pull Requests commits to our mailing list.
>  
>  Please read ["A note from the maintainer"](https://git.kernel.org/pub/scm/git/git.git/plain/MaintNotes?h=todo)
> diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
> index adba13e5ba..85911a44e2 100644
> --- a/.github/PULL_REQUEST_TEMPLATE.md
> +++ b/.github/PULL_REQUEST_TEMPLATE.md
> @@ -1,7 +1,7 @@
>  Thanks for taking the time to contribute to Git! Please be advised that the
>  Git community does not use github.com for their contributions. Instead, we use
>  a mailing list (git@vger.kernel.org) for code submissions, code reviews, and
> -bug reports. Nevertheless, you can use submitGit to conveniently send your Pull
> -Requests commits to our mailing list.
> +bug reports. Nevertheless, you can use Git Git Gadget (https://gitgitgadget.github.io/)
> +to conveniently send your Pull Requests commits to our mailing list.
>  
>  Please read the "guidelines for contributing" linked above!

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Jeff King <peff@peff.net> writes:
>
>> -Nevertheless, you can use [submitGit](http://submitgit.herokuapp.com/) to
>> +Nevertheless, you can use [Git Git Gadget](https://gitgitgadget.github.io/) to
>
> The pointed-at page calls the tool a single word with three capital
> Gs without SP in it.  We should match it here and in the other
> document.

For now, here is what I have locally.  Again, thanks all.

-- >8 --
From: Jeff King <peff@peff.net>
Date: Tue, 12 Mar 2019 17:32:46 -0400
Subject: [PATCH] point pull requesters to GitGitGadget

In the contributing guide and PR template seen by people who open pull
requests on GitHub, we mention the submitGit tool, which gives an
alternative to figuring out the mailing list. These days we also have
the similar GitGitGadget tool, and we should make it clear that this
is also an option.

We could continue to mention _both_ tools, but it's probably better to
pick one in order to avoid overwhelming the user with choice. After all,
one of the purposes here is to reduce friction for first-time or
infrequent contributors. And there are a few reasons to prefer GGG:

  1. submitGit seems to still have a few rough edges. E.g., it doesn't
     munge timestamps to help threaded mail readers handled out-of-order
     delivery.

  2. Subjectively, GGG seems to be more commonly used on the list these
     days, especially by list regulars.

  3. GGG seems to be under more active development (likely related to
     point 2).

So let's actually swap out submitGit for GGG. While we're there, let's
put another link to the GGG page in the PR template, because that's
where users who are learning about it for the first time will want to go
to read more.

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Roberto Tyley <roberto.tyley@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 .github/CONTRIBUTING.md          | 2 +-
 .github/PULL_REQUEST_TEMPLATE.md | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
index 64e605a02b..e7b4e2f3c2 100644
--- a/.github/CONTRIBUTING.md
+++ b/.github/CONTRIBUTING.md
@@ -5,7 +5,7 @@ Git community does not use github.com for their contributions. Instead, we use
 a mailing list (git@vger.kernel.org) for code submissions, code
 reviews, and bug reports.
 
-Nevertheless, you can use [submitGit](http://submitgit.herokuapp.com/) to
+Nevertheless, you can use [GitGitGadget](https://gitgitgadget.github.io/) to
 conveniently send your Pull Requests commits to our mailing list.
 
 Please read ["A note from the maintainer"](https://git.kernel.org/pub/scm/git/git.git/plain/MaintNotes?h=todo)
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index adba13e5ba..952c7c3a2a 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -1,7 +1,7 @@
 Thanks for taking the time to contribute to Git! Please be advised that the
 Git community does not use github.com for their contributions. Instead, we use
 a mailing list (git@vger.kernel.org) for code submissions, code reviews, and
-bug reports. Nevertheless, you can use submitGit to conveniently send your Pull
-Requests commits to our mailing list.
+bug reports. Nevertheless, you can use GitGitGadget (https://gitgitgadget.github.io/)
+to conveniently send your Pull Requests commits to our mailing list.
 
 Please read the "guidelines for contributing" linked above!
-- 
2.21.0-155-ge902e9bcae

Re: [RFC/PATCH] point pull requesters to Git Git Gadget

[Jeff King]

On Wed, Mar 13, 2019 at 11:18:25AM +0900, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Jeff King <peff@peff.net> writes:
> >
> >> -Nevertheless, you can use [submitGit](http://submitgit.herokuapp.com/) to
> >> +Nevertheless, you can use [Git Git Gadget](https://gitgitgadget.github.io/) to
> >
> > The pointed-at page calls the tool a single word with three capital
> > Gs without SP in it.  We should match it here and in the other
> > document.
> 
> For now, here is what I have locally.  Again, thanks all.

Yep, that makes sense. What you have queued looks good to me.

-Peff

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

[Johannes Schindelin]

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.

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

[Duy Nguyen]

On Thu, Mar 14, 2019 at 7:06 PM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> 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).

To be clear (and if I remember it correctly) that was the reaction to
how you took feedback on GitGitGadget. Not GitGitGadget itself.

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

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

[Jeff King]

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

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

[Johannes Schindelin]

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?

:-P

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.

Ciao,
Dscho

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

[Ævar Arnfjörð Bjarmason]

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@tvgsbejvaqbjf.bet/
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.

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

[Jeff King]

On Fri, Mar 15, 2019 at 05:28:08PM +0100, Ævar Arnfjörð Bjarmason wrote:

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

I think maybe you missed the patch that started this thread, which
proposes exactly that. :)

It should point people in the right direction, but of course getting GGG
directly on git/git means that they don't have to re-make their PR on a
different repo (though I guess they'd see the template while they're
making the PR, and IIRC it's no more difficult at that point than
clicking the destination repo box at the top of the page?).

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

There was some discussion of that elsewhere recently:

  https://public-inbox.org/git/20190311202441.GB18263@sigill.intra.peff.net/

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

That's where I'm at, too. I doubt I'd ever use it, because I really like
my workflow. But if it is working for other people, especially people
who might otherwise be turned off of contributing, that seems like a
good thing (as long as the quality of submissions is in the same
ballpark; I think it is, and improving the tooling should keep that
moving in the right direction).

-Peff