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

Hi Roberto,

On Tue, 12 Mar 2019, Roberto Tyley wrote:

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