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

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

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