| Message ID | 20190312213246.GA6252@sigill.intra.peff.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC/PATCH] point pull requesters to Git Git Gadget | expand |
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
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 ;-)
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!
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!
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
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
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
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
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).
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
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.
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
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.
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.
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
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
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
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
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.
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
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
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.
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
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
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
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
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.
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!
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(-)