{"thread":{"id":"50722","subject":"[RFC/PATCH] point pull requesters to Git Git Gadget","startedAt":"2019-03-12T21:34:05Z","lastAt":"2019-03-19T00:30:45Z","messageCount":28,"participants":["Jeff King","Roberto Tyley","Junio C Hamano","Johannes Schindelin","Duy Nguyen","Ævar Arnfjörð Bjarmason","Thomas Gummerer"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"371302","messageId":"20190312213246.GA6252@sigill.intra.peff.net","threadId":"50722","inReplyTo":null,"subject":"[RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-12T21:32:46Z","receivedAt":"2019-03-12T21:34:05Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"In the contributing guide and PR template seen by people who open pull\nrequests on GitHub, we mention the submitGit tool, which gives an\nalternative to figuring out the mailing list. These days we also have\nthe similar Git Git Gadget tool, and we should make it clear that this\nis also an option.\n\nWe could continue to mention _both_ tools, but it's probably better to\npick one in order to avoid overwhelming the user with choice. After all,\none of the purposes here is to reduce friction for first-time or\ninfrequent contributors. And there are a few reasons to prefer GGG:\n\n 1. submitGit seems to still have a few rough edges. E.g., it doesn't\n munge timestamps to help threaded mail readers handled out-of-order\n delivery.\n\n 2. Subjectively, GGG seems to be more commonly used on the list these\n days, especially by list regulars.\n\n 3. GGG seems to be under more active development (likely related to\n point 2).\n\nSo let's actually swap out submitGit for GGG. While we're there, let's\nput another link to the GGG page in the PR template, because that's\nwhere users who are learning about it for the first time will want to go\nto read more.\n\nSigned-off-by: Jeff King \n---\nI feel a little bad sending this, because I really value the work that\nRoberto has done on submitGit. So just dropping it feels a bit\ndismissive. But for the reasons above, it seems like GGG is going to be\nthe path forward, and it doesn't really make much sense to have two\ncompeting systems unless they have really different feature-sets or\napproaches (which I don't think is the case).\n\nSo I thought I'd mark this RFC and see what people thought. :)\n\nOne thing that I think submitGit can do that GGG cannot (yet), is just\ntake PRs straight on git/git. If we're going to start recommending it,\nthen I think we'd probably want to configure that, since it's one less\nconfusing step for first-timers, who right now might have to go re-make\ntheir PR on gitgitgadget/git.\n\n .github/CONTRIBUTING.md | 2 +-\n .github/PULL_REQUEST_TEMPLATE.md | 4 ++--\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md\nindex 64e605a02b..7e6df9e429 100644\n--- a/.github/CONTRIBUTING.md\n+++ b/.github/CONTRIBUTING.md\n@@ -5,7 +5,7 @@ Git community does not use github.com for their contributions. Instead, we use\n a mailing list (git@vger.kernel.org) for code submissions, code\n reviews, and bug reports.\n \n-Nevertheless, you can use [submitGit](http://submitgit.herokuapp.com/) to\n+Nevertheless, you can use [Git Git Gadget](https://gitgitgadget.github.io/) to\n conveniently send your Pull Requests commits to our mailing list.\n \n Please read [\"A note from the maintainer\"](https://git.kernel.org/pub/scm/git/git.git/plain/MaintNotes?h=todo)\ndiff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md\nindex adba13e5ba..85911a44e2 100644\n--- a/.github/PULL_REQUEST_TEMPLATE.md\n+++ b/.github/PULL_REQUEST_TEMPLATE.md\n@@ -1,7 +1,7 @@\n Thanks for taking the time to contribute to Git! Please be advised that the\n Git community does not use github.com for their contributions. Instead, we use\n a mailing list (git@vger.kernel.org) for code submissions, code reviews, and\n-bug reports. Nevertheless, you can use submitGit to conveniently send your Pull\n-Requests commits to our mailing list.\n+bug reports. Nevertheless, you can use Git Git Gadget (https://gitgitgadget.github.io/)\n+to conveniently send your Pull Requests commits to our mailing list.\n \n Please read the \"guidelines for contributing\" linked above!\n-- \n2.21.0.539.gcf54785f87\n"},{"id":"371307","messageId":"CAFY1edYQcWzYJXF6f_TRk4=bEMVnFXTAp=5u=TJ4XZ3UUd4EmA@mail.gmail.com","threadId":"50722","inReplyTo":"20190312213246.GA6252@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Roberto Tyley","fromEmail":"roberto.tyley@gmail.com","sentAt":"2019-03-12T23:08:00Z","receivedAt":"2019-03-12T23:08:13Z","isPatch":true,"sender":{"key":"roberto.tyley@gmail.com","avatar":"https://avatars.githubusercontent.com/u/52038?v=4"},"body":"On Tue, 12 Mar 2019 at 21:34, Jeff King wrote:\n...\n> We could continue to mention _both_ tools, but it's probably better to\n> pick one in order to avoid overwhelming the user with choice. After all,\n> one of the purposes here is to reduce friction for first-time or\n> infrequent contributors. And there are a few reasons to prefer GGG:\n\nThat's fair enough - I haven't committed to submitGit for 2 years\n(it's continued to work without incident for most of that time I\nthink!). I would be prepared to spend more time on it if it was\nimportant to people - or, heavens forfend, I could be paid to do so :)\n - but I have a lot of projects (not just software ones!) and\nsubmitGit kind of fell to the bottom of the pile. I wasn't aware of\nhttps://gitgitgadget.github.io/ but it looks good!\n\n> 1. submitGit seems to still have a few rough edges. E.g., it doesn't\n> munge timestamps to help threaded mail readers handled out-of-order\n> delivery.\n\nYup, very true.\n\n> 2. Subjectively, GGG seems to be more commonly used on the list these\n> days, especially by list regulars.\n\nThat's probably true too, though my interest with submitGit was more\ndriven by helping early/first-time contributors than regulars. Though\nI'm sure GGG works well, in an ideal world it would be interesting to\nget a perspective from a cohort of those kind of users about what kind\nof flow works best for them - although, as I haven't been following\ndevelopment, maybe this has already been done?\n\n> 3. GGG seems to be under more active development (likely related to\n> point 2).\n\nDefinitely true!\n\n> I feel a little bad sending this, because I really value the work that\n> Roberto has done on submitGit. So just dropping it feels a bit\n> dismissive.\n\nOh, you're very kind, that's ok! Very glad submitGit could help for a\nwhile, sounds like it was a good proof that GitHub could become part\nof the contribution process.\n\nRoberto\n"},{"id":"371317","messageId":"xmqqsgvrfsrh.fsf@gitster-ct.c.googlers.com","threadId":"50722","inReplyTo":"20190312213246.GA6252@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-03-13T01:49:22Z","receivedAt":"2019-03-13T01:49:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> infrequent contributors. And there are a few reasons to prefer GGG:\n>\n> 1. submitGit seems to still have a few rough edges. E.g., it doesn't\n> munge timestamps to help threaded mail readers handled out-of-order\n> delivery.\n\nHmph, I had an impression that the recent \"why aren't these sorted\"\ntopics were via GGG, not submitGit, though.\n\n\n> 2. Subjectively, GGG seems to be more commonly used on the list these\n> days, especially by list regulars.\n>\n> 3. GGG seems to be under more active development (likely related to\n> point 2).\n>\n> So let's actually swap out submitGit for GGG. While we're there, let's\n> put another link to the GGG page in the PR template, because that's\n> where users who are learning about it for the first time will want to go\n> to read more.\n\nYeah, I see Roberto agrees with the direction, and I do too.\n\nThanks, Roberto for submitGit that served us well, Dscho for GGG\nthat will serve us better, and Peff for updating this ;-)\n"},{"id":"371321","messageId":"xmqqef7bfrxv.fsf@gitster-ct.c.googlers.com","threadId":"50722","inReplyTo":"20190312213246.GA6252@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-03-13T02:07:08Z","receivedAt":"2019-03-13T02:07:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> -Nevertheless, you can use [submitGit](http://submitgit.herokuapp.com/) to\n> +Nevertheless, you can use [Git Git Gadget](https://gitgitgadget.github.io/) to\n\nThe pointed-at page calls the tool a single word with three capital\nGs without SP in it. We should match it here and in the other\ndocument.\n\n> conveniently send your Pull Requests commits to our mailing list.\n> \n> Please read [\"A note from the maintainer\"](https://git.kernel.org/pub/scm/git/git.git/plain/MaintNotes?h=todo)\n> diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md\n> index adba13e5ba..85911a44e2 100644\n> --- a/.github/PULL_REQUEST_TEMPLATE.md\n> +++ b/.github/PULL_REQUEST_TEMPLATE.md\n> @@ -1,7 +1,7 @@\n> Thanks for taking the time to contribute to Git! Please be advised that the\n> Git community does not use github.com for their contributions. Instead, we use\n> a mailing list (git@vger.kernel.org) for code submissions, code reviews, and\n> -bug reports. Nevertheless, you can use submitGit to conveniently send your Pull\n> -Requests commits to our mailing list.\n> +bug reports. Nevertheless, you can use Git Git Gadget (https://gitgitgadget.github.io/)\n> +to conveniently send your Pull Requests commits to our mailing list.\n> \n> Please read the \"guidelines for contributing\" linked above!\n"},{"id":"371324","messageId":"xmqq1s3bfrf2.fsf@gitster-ct.c.googlers.com","threadId":"50722","inReplyTo":"xmqqef7bfrxv.fsf@gitster-ct.c.googlers.com","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-03-13T02:18:25Z","receivedAt":"2019-03-13T02:18:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jeff King writes:\n>\n>> -Nevertheless, you can use [submitGit](http://submitgit.herokuapp.com/) to\n>> +Nevertheless, you can use [Git Git Gadget](https://gitgitgadget.github.io/) to\n>\n> The pointed-at page calls the tool a single word with three capital\n> Gs without SP in it. We should match it here and in the other\n> document.\n\nFor now, here is what I have locally. Again, thanks all.\n\n-- >8 --\nFrom: Jeff King \nDate: Tue, 12 Mar 2019 17:32:46 -0400\nSubject: [PATCH] point pull requesters to GitGitGadget\n\nIn the contributing guide and PR template seen by people who open pull\nrequests on GitHub, we mention the submitGit tool, which gives an\nalternative to figuring out the mailing list. These days we also have\nthe similar GitGitGadget tool, and we should make it clear that this\nis also an option.\n\nWe could continue to mention _both_ tools, but it's probably better to\npick one in order to avoid overwhelming the user with choice. After all,\none of the purposes here is to reduce friction for first-time or\ninfrequent contributors. And there are a few reasons to prefer GGG:\n\n 1. submitGit seems to still have a few rough edges. E.g., it doesn't\n munge timestamps to help threaded mail readers handled out-of-order\n delivery.\n\n 2. Subjectively, GGG seems to be more commonly used on the list these\n days, especially by list regulars.\n\n 3. GGG seems to be under more active development (likely related to\n point 2).\n\nSo let's actually swap out submitGit for GGG. While we're there, let's\nput another link to the GGG page in the PR template, because that's\nwhere users who are learning about it for the first time will want to go\nto read more.\n\nSigned-off-by: Jeff King \nAcked-by: Roberto Tyley \nSigned-off-by: Junio C Hamano \n---\n .github/CONTRIBUTING.md | 2 +-\n .github/PULL_REQUEST_TEMPLATE.md | 4 ++--\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md\nindex 64e605a02b..e7b4e2f3c2 100644\n--- a/.github/CONTRIBUTING.md\n+++ b/.github/CONTRIBUTING.md\n@@ -5,7 +5,7 @@ Git community does not use github.com for their contributions. Instead, we use\n a mailing list (git@vger.kernel.org) for code submissions, code\n reviews, and bug reports.\n \n-Nevertheless, you can use [submitGit](http://submitgit.herokuapp.com/) to\n+Nevertheless, you can use [GitGitGadget](https://gitgitgadget.github.io/) to\n conveniently send your Pull Requests commits to our mailing list.\n \n Please read [\"A note from the maintainer\"](https://git.kernel.org/pub/scm/git/git.git/plain/MaintNotes?h=todo)\ndiff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md\nindex adba13e5ba..952c7c3a2a 100644\n--- a/.github/PULL_REQUEST_TEMPLATE.md\n+++ b/.github/PULL_REQUEST_TEMPLATE.md\n@@ -1,7 +1,7 @@\n Thanks for taking the time to contribute to Git! Please be advised that the\n Git community does not use github.com for their contributions. Instead, we use\n a mailing list (git@vger.kernel.org) for code submissions, code reviews, and\n-bug reports. Nevertheless, you can use submitGit to conveniently send your Pull\n-Requests commits to our mailing list.\n+bug reports. Nevertheless, you can use GitGitGadget (https://gitgitgadget.github.io/)\n+to conveniently send your Pull Requests commits to our mailing list.\n \n Please read the \"guidelines for contributing\" linked above!\n-- \n2.21.0-155-ge902e9bcae\n\n"},{"id":"371393","messageId":"20190313193436.GA3400@sigill.intra.peff.net","threadId":"50722","inReplyTo":"CAFY1edYQcWzYJXF6f_TRk4=bEMVnFXTAp=5u=TJ4XZ3UUd4EmA@mail.gmail.com","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-13T19:34:37Z","receivedAt":"2019-03-13T19:35:55Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 12, 2019 at 11:08:00PM +0000, Roberto Tyley wrote:\n\n> On Tue, 12 Mar 2019 at 21:34, Jeff King wrote:\n> ...\n> > We could continue to mention _both_ tools, but it's probably better to\n> > pick one in order to avoid overwhelming the user with choice. After all,\n> > one of the purposes here is to reduce friction for first-time or\n> > infrequent contributors. And there are a few reasons to prefer GGG:\n> \n> That's fair enough - I haven't committed to submitGit for 2 years\n> (it's continued to work without incident for most of that time I\n> think!).\n\nYeah, it has been working fine as far as I know. I was a little curious\nabout how often (and about my impression that GGG was replacing it), so\nI did some quick mining of the list archive. Here are numbers of\nmessages each month (from the last ~100k messages) mentioning Amazon SES\n(presumably submitGit) or GitGitGadget in the message-id. I omitted\nmonths with no entries for either, so there are some gaps:\n\n ses ggg year-mo\n --- --- -------\n 7 0 2015-07\n 2 0 2015-08\n 3 0 2015-09\n 1 0 2015-11\n 2 0 2016-01\n 3 0 2016-02\n 34 0 2016-03\n 27 0 2016-04\n 2 0 2016-05\n 6 0 2016-06\n 26 0 2016-07\n 54 0 2016-08\n 3 0 2016-09\n 29 0 2016-10\n 3 0 2016-12\n 4 0 2017-01\n 7 0 2017-03\n 5 0 2017-04\n 3 0 2017-05\n 23 0 2017-06\n 9 0 2017-07\n 14 0 2017-09\n 6 0 2017-10\n 8 0 2017-11\n 8 0 2017-12\n 38 0 2018-01\n 86 0 2018-02\n 49 0 2018-03\n 9 0 2018-04\n 1 0 2018-05\n 3 4 2018-06\n 0 86 2018-07\n 13 105 2018-08\n 0 65 2018-09\n 14 149 2018-10\n 7 131 2018-11\n 1 46 2018-12\n 14 96 2019-01\n 16 149 2019-02\n 0 44 2019-03\n\nThat measures pure patches, so they tend to cluster as there are often\nseveral patches in a series. Poking manually at the ses hits, submitGit\nseems to have been often used by GSoC and Outreachy applicants and\ninterns.\n\nI don't know if any of this really supports or refutes my earlier commit\nmessage, but I just thought it was kind of neat to see the numbers, so I\nthought I'd share.\n\n> > 2. Subjectively, GGG seems to be more commonly used on the list these\n> > days, especially by list regulars.\n> \n> That's probably true too, though my interest with submitGit was more\n> driven by helping early/first-time contributors than regulars. Though\n> I'm sure GGG works well, in an ideal world it would be interesting to\n> get a perspective from a cohort of those kind of users about what kind\n> of flow works best for them - although, as I haven't been following\n> development, maybe this has already been done?\n\nI think the flow is quite similar, and GGG is definitely geared at\nhelping infrequent contributors, too. Dscho might have more thoughts on\nthis.\n\nThe biggest friction is marking a user as allowed to send. I think in\nsubmitGit you have to \"OK\" the submitGit app sending on your behalf. In\nGGG, somebody who already has been OK'd has to OK you with a comment in\nthe PR (after which you're approved for future PRs, too). It's possible\nthe approval could slow things down, but I think as long as users of the\ntool are fairly prompt about approving non-spam PRs, it wouldn't be a\nbig deal.\n\n> > I feel a little bad sending this, because I really value the work that\n> > Roberto has done on submitGit. So just dropping it feels a bit\n> > dismissive.\n> \n> Oh, you're very kind, that's ok! Very glad submitGit could help for a\n> while, sounds like it was a good proof that GitHub could become part\n> of the contribution process.\n\nYes, I think it definitely was.\n\n-Peff\n"},{"id":"371394","messageId":"20190313193909.GB3400@sigill.intra.peff.net","threadId":"50722","inReplyTo":"xmqqsgvrfsrh.fsf@gitster-ct.c.googlers.com","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-13T19:39:09Z","receivedAt":"2019-03-13T19:40:28Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 13, 2019 at 10:49:22AM +0900, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > infrequent contributors. And there are a few reasons to prefer GGG:\n> >\n> > 1. submitGit seems to still have a few rough edges. E.g., it doesn't\n> > munge timestamps to help threaded mail readers handled out-of-order\n> > delivery.\n> \n> Hmph, I had an impression that the recent \"why aren't these sorted\"\n> topics were via GGG, not submitGit, though.\n\nWe did have one case a few months ago, but I think it was since fixed.\nWhereas it cannot be fixed for submitGit without major re-architecting,\nbecause the mails go out through Amazon SES, which writes its own\ntimestamp.\n\nI could be wrong about GGG being fixed though. I haven't noticed the\nproblem lately, but we definitely had a submitGit-related one a few\nweeks ago.\n\n-Peff\n"},{"id":"371395","messageId":"20190313193937.GC3400@sigill.intra.peff.net","threadId":"50722","inReplyTo":"xmqq1s3bfrf2.fsf@gitster-ct.c.googlers.com","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-13T19:39:37Z","receivedAt":"2019-03-13T19:40:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 13, 2019 at 11:18:25AM +0900, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > Jeff King writes:\n> >\n> >> -Nevertheless, you can use [submitGit](http://submitgit.herokuapp.com/) to\n> >> +Nevertheless, you can use [Git Git Gadget](https://gitgitgadget.github.io/) to\n> >\n> > The pointed-at page calls the tool a single word with three capital\n> > Gs without SP in it. We should match it here and in the other\n> > document.\n> \n> For now, here is what I have locally. Again, thanks all.\n\nYep, that makes sense. What you have queued looks good to me.\n\n-Peff\n"},{"id":"371396","messageId":"20190313201854.GA5530@sigill.intra.peff.net","threadId":"50722","inReplyTo":"20190313193909.GB3400@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-13T20:18:54Z","receivedAt":"2019-03-13T20:20:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 13, 2019 at 03:39:09PM -0400, Jeff King wrote:\n\n> On Wed, Mar 13, 2019 at 10:49:22AM +0900, Junio C Hamano wrote:\n> \n> > Jeff King writes:\n> > \n> > > infrequent contributors. And there are a few reasons to prefer GGG:\n> > >\n> > > 1. submitGit seems to still have a few rough edges. E.g., it doesn't\n> > > munge timestamps to help threaded mail readers handled out-of-order\n> > > delivery.\n> > \n> > Hmph, I had an impression that the recent \"why aren't these sorted\"\n> > topics were via GGG, not submitGit, though.\n> \n> We did have one case a few months ago, but I think it was since fixed.\n> Whereas it cannot be fixed for submitGit without major re-architecting,\n> because the mails go out through Amazon SES, which writes its own\n> timestamp.\n> \n> I could be wrong about GGG being fixed though. I haven't noticed the\n> problem lately, but we definitely had a submitGit-related one a few\n> weeks ago.\n\nHmm. I guess it is still an issue in GGG. This thread has identical\ntimestamps on patches 1 and 2 (and my server received them out of order\nby 2 seconds, so mutt orders them wrong):\n\n https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/\n\nI do still think GGG has a more feasible path forward on this particular\nbug, though.\n\n-Peff\n"},{"id":"371400","messageId":"nycvar.QRO.7.76.6.1903132119160.41@tvgsbejvaqbjf.bet","threadId":"50722","inReplyTo":"CAFY1edYQcWzYJXF6f_TRk4=bEMVnFXTAp=5u=TJ4XZ3UUd4EmA@mail.gmail.com","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-03-13T20:50:53Z","receivedAt":"2019-03-13T20:51:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Roberto,\n\nOn Tue, 12 Mar 2019, Roberto Tyley wrote:\n\n> On Tue, 12 Mar 2019 at 21:34, Jeff King wrote:\n> \n> > I feel a little bad sending this, because I really value the work that\n> > Roberto has done on submitGit. So just dropping it feels a bit\n> > dismissive.\n> \n> Oh, you're very kind, that's ok! Very glad submitGit could help for a\n> while, sounds like it was a good proof that GitHub could become part of\n> the contribution process.\n\nTBH I also felt quite bad for starting GitGitGadget rather than extending\nsubmitGit. It's just that I faced too many obstacles with that:\n\n- submitGit is stateless. I have *no* way of automatically including a\n range-diff.\n\n- I remember that there were rather huge concerns about giving Amazon the\n keys to your email. This is so intricate a part of submitGit's design\n (even if you would change it to use another service to send mails in\n your name, you would still have to trust *some* service with your\n credentials).\n\n- One of the things I *really* wanted was to have the tool mirror the\n replies on the mailing list back to the PR. Since submitGit does not\n *really* integrate with the GitHub interface (it might read some\n information, but it won't interact with the user there, opting instead\n on its own web interface), that was not something I could see submitGit\n to learn.\n\n- Since submitGit does not write any state, there was no way to persist\n previous iterations in the form of the tags that GitGitGadget publishes.\n\n- Finally, I never hid my concern about the choice of language (Scala\n might be a nice language to learn, even for me, some day, but trying\n to force people like me to learn a language that they did not plan on\n learning is probably a bad idea). I probably was too vocal about this,\n at times. And I still feel very strongly about this. Choosing a language\n that many developers of the target audience do *not* speak already is\n (in my mind) putting an unnecessary hurdle in front of contributors.\n\nRegarding Scala: Granted, with Typescript rather than Javascript, I chose\nanother not-quite-mainstream language. But Scale is not even mentioned in\nhttps://www.benfrederickson.com/ranking-programming-languages-by-github-users/\nwhile Typescript is definitely an \"up-and-coming language\".\n\nAlso, I always wanted to learn how to write web applications, and this was\na perfect excuse to do so.\n\nNevermind that I had to convert this to a serverless part (an Azure\nFunction) with a user-visible backend (an Azure Pipeline that updates the\nPR Check on GitHub and makes it easy to review the log, just in case\nanything failed during the mail sending process). Due to the environment\n(see below) this conversion was relatively painless, and you have *no*\nidea how pleased I am that *nobody* realized that GitGitGadget underwent\nsuch a rather dramatic architecture change. I essentially replaced the\nengine of a Nascar machine with a differently-sized one, while the race\nwas still on.\n\nIn addition, I wanted to know what all this Typescript hype was all about,\nand I was surprised just how many bugs were caught in my original\nmail-patch-series.sh [*1*] that I converted to Javascript and then to\nTypescript, by the mere fact of converting to Typescript. I also have to\nadmit that it felt quite pleasant to be able to use object-oriented\nscripting, with an infrastructure of dependencies at your fingertips\n(npm), and almost pain-free, portable, fast, intuitive unit testing\n(jest).\n\nSo I am thankful for submitGit, and at the same time I still feel that it\nwas necessary to pit GitGitGadget against it. Almost as if (from my\nperspective) the purpose of submitGit was to prod me into starting\nGitGitGadget, to show what is possible.\n\nCiao,\nDscho\n\nFootnote *1*: I originally used a shell script called\n`mail-patch-series.sh` to submit my patch series, and later even published\nit at https://github.com/dscho/mail-patch-series in the hopes that it\nwould benefit others (and that I'd get PRs to improve it). I learned,\nhowever, that nobody wants to use anybody else's shell script to submit\ntheir patch series, just like I found e.g. Lars Schneider's automatic\nreviewer Cc:ing too broad, others did not like my choices like storing the\ncover letter in the branch description (which is by definition not\npushable).\n"},{"id":"371403","messageId":"nycvar.QRO.7.76.6.1903132153480.41@tvgsbejvaqbjf.bet","threadId":"50722","inReplyTo":"20190313193909.GB3400@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-03-13T21:05:22Z","receivedAt":"2019-03-13T21:05:37Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 13 Mar 2019, Jeff King wrote:\n\n> On Wed, Mar 13, 2019 at 10:49:22AM +0900, Junio C Hamano wrote:\n> \n> > Jeff King writes:\n> > \n> > > infrequent contributors. And there are a few reasons to prefer GGG:\n> > >\n> > > 1. submitGit seems to still have a few rough edges. E.g., it doesn't\n> > > munge timestamps to help threaded mail readers handled out-of-order\n> > > delivery.\n> > \n> > Hmph, I had an impression that the recent \"why aren't these sorted\"\n> > topics were via GGG, not submitGit, though.\n\nHmph. I thought these were sorted out by\nhttps://github.com/gitgitgadget/gitgitgadget/pull/23...\n\nJunio, if you are referring to your complaint in\nhttps://public-inbox.org/git/xmqqftt83bt9.fsf@gitster-ct.c.googlers.com/,\nI just had a look, and the dates of JeffH's 00/14, 01/14 and 02/14 were,\nrespectively,\n\nDate: Tue, 22 Jan 2019 13:22:12 -0800 (PST)\nDate: Tue, 22 Jan 2019 13:22:12 -0800 (PST)\nand\nDate: Tue, 22 Jan 2019 13:22:14 -0800 (PST)\n\nNot quite what PR #23 tried to achieve. So where does this problem come\nfrom? A little further digging reveals another, quite revealing header:\n\nX-Google-Original-Date: Tue, 22 Jan 2019 21:21:57 GMT\nX-Google-Original-Date: Tue, 22 Jan 2019 21:21:58 GMT\nand\nX-Google-Original-Date: Tue, 22 Jan 2019 21:21:59 GMT\n\nwhich makes a ton more sense because GitGitGadget would not ever use -0800\nas generic timezone.\n\n(to see for yourself, just direct your browser to\nhttps://public-inbox.org/git/pull.108.git.gitgitgadget@gmail.com/raw\nhttps://public-inbox.org/git/1a90de9dab0dd836e54fee9e08ab9e2284e1027a.1548192131.git.gitgitgadget@gmail.com/raw\nand\nhttps://public-inbox.org/git/4aaf4834bfa9f2169e2c00f7cdc6c75281567c15.1548192131.git.gitgitgadget@gmail.com/raw)\n\nSo the *real* problem is that your GMail developer colleagues, Junio,\ndecide that GitGitGadget's Date: header is not good enough, and override\nit by a less useful version.\n\n:-)\n\n> We did have one case a few months ago, but I think it was since fixed.\n> Whereas it cannot be fixed for submitGit without major re-architecting,\n> because the mails go out through Amazon SES, which writes its own\n> timestamp.\n> \n> I could be wrong about GGG being fixed though. I haven't noticed the\n> problem lately, but we definitely had a submitGit-related one a few\n> weeks ago.\n\nMaybe you use two different versions of mutt?\n\n*ducks* ;-)\n\nI come more and more to the conclusion that you can use whatever mail\nclient to read the Git mailing list, as long as it is mutt. Which leaves\nme behind, as an Alpine (and occasional Thunderbird and Roundcube Mail)\nuser...\n\nCiao,\nDscho\n"},{"id":"371407","messageId":"xmqq36nqe7w6.fsf@gitster-ct.c.googlers.com","threadId":"50722","inReplyTo":"20190313193909.GB3400@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-03-13T22:17:45Z","receivedAt":"2019-03-13T22:17:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Mar 13, 2019 at 10:49:22AM +0900, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>> \n>> > infrequent contributors. And there are a few reasons to prefer GGG:\n>> >\n>> > 1. submitGit seems to still have a few rough edges. E.g., it doesn't\n>> > munge timestamps to help threaded mail readers handled out-of-order\n>> > delivery.\n>> \n>> Hmph, I had an impression that the recent \"why aren't these sorted\"\n>> topics were via GGG, not submitGit, though.\n>\n> We did have one case a few months ago, but I think it was since fixed.\n>\n> Whereas it cannot be fixed for submitGit without major re-architecting,\n> because the mails go out through Amazon SES, which writes its own\n> timestamp.\n>\n> I could be wrong about GGG being fixed though. I haven't noticed the\n> problem lately, but we definitely had a submitGit-related one a few\n> weeks ago.\n\nYeah, I was confused; \nwas about submitGit, but somehow I thought the sender switched to,\nand the out-of-order thread was sent via, GGG. My mistake.\n\n\n"},{"id":"371481","messageId":"nycvar.QRO.7.76.6.1903141228510.41@tvgsbejvaqbjf.bet","threadId":"50722","inReplyTo":"20190313201854.GA5530@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-03-14T11:31:21Z","receivedAt":"2019-03-14T11:31:51Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Wed, 13 Mar 2019, Jeff King wrote:\n\n> On Wed, Mar 13, 2019 at 03:39:09PM -0400, Jeff King wrote:\n> \n> > On Wed, Mar 13, 2019 at 10:49:22AM +0900, Junio C Hamano wrote:\n> > \n> > > Jeff King writes:\n> > > \n> > > > infrequent contributors. And there are a few reasons to prefer GGG:\n> > > >\n> > > > 1. submitGit seems to still have a few rough edges. E.g., it doesn't\n> > > > munge timestamps to help threaded mail readers handled out-of-order\n> > > > delivery.\n> > > \n> > > Hmph, I had an impression that the recent \"why aren't these sorted\"\n> > > topics were via GGG, not submitGit, though.\n> > \n> > We did have one case a few months ago, but I think it was since fixed.\n> > Whereas it cannot be fixed for submitGit without major re-architecting,\n> > because the mails go out through Amazon SES, which writes its own\n> > timestamp.\n> > \n> > I could be wrong about GGG being fixed though. I haven't noticed the\n> > problem lately, but we definitely had a submitGit-related one a few\n> > weeks ago.\n> \n> Hmm. I guess it is still an issue in GGG. This thread has identical\n> timestamps on patches 1 and 2 (and my server received them out of order\n> by 2 seconds, so mutt orders them wrong):\n> \n> https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/\n> \n> I do still think GGG has a more feasible path forward on this particular\n> bug, though.\n\nIndeed. And it is a bug^Wfeature of GMail, I guess, that it knows better\nand ignores the Date: header of the mbox fed to it.\n\nThe only workaround I can think of is to introduce ugly one-second-sleeps.\nI will do that if it proves necessary, but I do have a problem right now\nbecause my only GitGitGadget reviewer (Stolee) is kinda busy with other\nthings for the time being.\n\nCiao,\nDscho\n"},{"id":"371482","messageId":"nycvar.QRO.7.76.6.1903141235390.41@tvgsbejvaqbjf.bet","threadId":"50722","inReplyTo":"20190312213246.GA6252@sigill.intra.peff.net","subject":"GitGitGadget on github.com/git/git?, was Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-03-14T12:04:51Z","receivedAt":"2019-03-14T12:05:16Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Tue, 12 Mar 2019, Jeff King wrote:\n\n> One thing that I think submitGit can do that GGG cannot (yet), is just\n> take PRs straight on git/git. If we're going to start recommending it,\n> then I think we'd probably want to configure that, since it's one less\n> confusing step for first-timers, who right now might have to go re-make\n> their PR on gitgitgadget/git.\n\nI just realized that I had not responded to that yet. It is not *quite*\nthat easy, unfortunately.\n\nI did design GitGitGadget to have a state. For example, to avoid spamming\nthe Git mailing list with bogus patch series, GitGitGadget maintains a\nlist of GitHub user names for users allowed to send patch series. (I saw\nmy share of bogus PRs in the Git for Windows fork, and had no desire to\nfacilitate similar patch series on the list.) This information, together\nwith information about the Message IDs to monitor, and about the PRs that\nare still open, are maintained in a JSON-formatted object that is stored\nin `refs/notes/gitgitgadget`.\n\nI also designed GitGitGadget to tag iterations it sent, and to push those\ntags to the public repository. I personally find it pretty frustrating\njust *how hard* it is to go from a given mail in the mailing list archive\nto a fully working local branch, even if that was exactly what the\noriginal contributor had to begin with. With these tags (of the form\npr-103/slavicaDj/add-i-v5), that's not a problem.\n\nNow, I was rather certain that Junio would *not* want that Git note in\nhttps://github.com/git/git, let alone all those tags.\n\nYet for ease of implementation, GitGitGadget uses the very same fork where\nthe GitGitGadget PRs live to push those refs.\n\nI could imagine that we keep pushing those refs to gitgitgadget/git, but\nnow also allow for PRs on git/git to use GitGitGadget (we would have to\ninstall the GitHub App there, too, and I would have to change the code to\nallow that, and we would have to use a slightly different format for the\ntags generated from git/git PRs to avoid clashes with the gitgitgadget/git\nPRs, all of which is totally doable).\n\nIf this is truly something we (\"we\" as in \"engaged Git developers\") want,\nI can set aside some time to work on that. I had originally planned on\nexactly that, i.e. supporting PRs on git/git, but I got rather strong\nindications that GitGitGadget is hated by some (Duy, for example, was very\nvocal about refusing to even look at any of the GitGitGadget-sent patch\nseries, let alone using the tool himself). While I think that this hate is\nundeserved, I cannot change other people's feelings, nor would I try, all\nI can do is to try not to make the situation worse.\n\nIn short: before I spend serious time on extending GitGitGadget to handle\ngit/git PRs, I want to be sure that I won't get backlash for that.\n\nCiao,\nDscho\n\nP.S.: Fun fact: I came up with the name while discussing the idea of the\n\"UI\" (using PR comments to send commands and get answers) with Stolee,\npretty much precisely a year ago, and when I tried to find a label for\nwhat this thing that I have in mind is all about, it was \"kind of a gadget\nthat works on git.git\".\n\nSo yeah, I had https://github.com/git/git PRs in mind when I started, and\nI only started the gitgitgadget/git fork in order to prove that it works,\nand that it has benefits.\n\nIf it was not for my wonderfully supportive team, I would probably have\nabandoned it after encountering so many pushbacks (`amlog` being actively\nmade useless for me, the unexpectedly negative reactions to GitGitGadget,\nall the work being left to me, etc). But my outstanding teammates really\nmade a difference, and can now reap the benefits of having a system that\nonly requires a GitHub account to contribute to Git. As well as occasional\ncontributors, I might want to add, whose contributions we would have lost\nif it was not for GitGitGadget.\n"},{"id":"371503","messageId":"CACsJy8AA_b7NKhoKg-qoGae92antzaE6WPd+P8LkD6zFc20VSg@mail.gmail.com","threadId":"50722","inReplyTo":"nycvar.QRO.7.76.6.1903141235390.41@tvgsbejvaqbjf.bet","subject":"Re: GitGitGadget on github.com/git/git?, was Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2019-03-14T14:46:24Z","receivedAt":"2019-03-14T14:46:53Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Mar 14, 2019 at 7:06 PM Johannes Schindelin\n wrote:\n> If this is truly something we (\"we\" as in \"engaged Git developers\") want,\n> I can set aside some time to work on that. I had originally planned on\n> exactly that, i.e. supporting PRs on git/git, but I got rather strong\n> indications that GitGitGadget is hated by some (Duy, for example, was very\n> vocal about refusing to even look at any of the GitGitGadget-sent patch\n> series, let alone using the tool himself).\n\nTo be clear (and if I remember it correctly) that was the reaction to\nhow you took feedback on GitGitGadget. Not GitGitGadget itself.\n\n> While I think that this hate is\n> undeserved, I cannot change other people's feelings, nor would I try, all\n> I can do is to try not to make the situation worse.\n-- \nDuy\n"},{"id":"371559","messageId":"20190315031948.GD28943@sigill.intra.peff.net","threadId":"50722","inReplyTo":"nycvar.QRO.7.76.6.1903141228510.41@tvgsbejvaqbjf.bet","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-15T03:19:48Z","receivedAt":"2019-03-15T03:21:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 14, 2019 at 12:31:21PM +0100, Johannes Schindelin wrote:\n\n> > Hmm. I guess it is still an issue in GGG. This thread has identical\n> > timestamps on patches 1 and 2 (and my server received them out of order\n> > by 2 seconds, so mutt orders them wrong):\n> > \n> > https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/\n> > \n> > I do still think GGG has a more feasible path forward on this particular\n> > bug, though.\n> \n> Indeed. And it is a bug^Wfeature of GMail, I guess, that it knows better\n> and ignores the Date: header of the mbox fed to it.\n\nHeh. So it in fact has the identical problem that submitGit and SES\nhave. :)\n\n> The only workaround I can think of is to introduce ugly one-second-sleeps.\n> I will do that if it proves necessary, but I do have a problem right now\n> because my only GitGitGadget reviewer (Stolee) is kinda busy with other\n> things for the time being.\n\nI suspect that may be the ultimate solution. Which isn't fantastic, but\nat the same time, I doubt anybody would really notice that much. There\nare typically delays of seconds to minutes already in delivering email.\nUnless somebody has a 200 patch series, but maybe then it is kinder to the\nreceivers to let it trickle in. ;)\n\n-Peff\n"},{"id":"371560","messageId":"20190315033020.GE28943@sigill.intra.peff.net","threadId":"50722","inReplyTo":"nycvar.QRO.7.76.6.1903141235390.41@tvgsbejvaqbjf.bet","subject":"Re: GitGitGadget on github.com/git/git?, was Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-15T03:30:20Z","receivedAt":"2019-03-15T03:30:59Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 14, 2019 at 01:04:51PM +0100, Johannes Schindelin wrote:\n\n> > One thing that I think submitGit can do that GGG cannot (yet), is just\n> > take PRs straight on git/git. If we're going to start recommending it,\n> > then I think we'd probably want to configure that, since it's one less\n> > confusing step for first-timers, who right now might have to go re-make\n> > their PR on gitgitgadget/git.\n> \n> I just realized that I had not responded to that yet. It is not *quite*\n> that easy, unfortunately.\n> \n> I did design GitGitGadget to have a state. For example, to avoid spamming\n> the Git mailing list with bogus patch series, GitGitGadget maintains a\n> list of GitHub user names for users allowed to send patch series. (I saw\n> my share of bogus PRs in the Git for Windows fork, and had no desire to\n> facilitate similar patch series on the list.) This information, together\n> with information about the Message IDs to monitor, and about the PRs that\n> are still open, are maintained in a JSON-formatted object that is stored\n> in `refs/notes/gitgitgadget`.\n\nAh, I wondered if there might be a catch like this. I do think it would\nbe nice to keep that ref out of git.git. We definitely would not want to\nlose the features that depend on it, but it sounds like we could use a\nseparate metadata repository.\n\n> I could imagine that we keep pushing those refs to gitgitgadget/git, but\n> now also allow for PRs on git/git to use GitGitGadget (we would have to\n> install the GitHub App there, too, and I would have to change the code to\n> allow that, and we would have to use a slightly different format for the\n> tags generated from git/git PRs to avoid clashes with the gitgitgadget/git\n> PRs, all of which is totally doable).\n\nI don't think connecting the GitHub App should be a big deal. Ideally it\nwould not even need write permission to the git/git repository, if it's\nkeeping metadata elsewhere (it would need to be able to write PR\ncomments, of course). It might not be a show-stopper if GitHub's\npermissions aren't fine-grained enough to allow that, but not having\nrepo write access would be nice insurance against bugs in GitGitGadget\nwriting where we don't expect it to.\n\n> If this is truly something we (\"we\" as in \"engaged Git developers\") want,\n> I can set aside some time to work on that. I had originally planned on\n> exactly that, i.e. supporting PRs on git/git, but I got rather strong\n> indications that GitGitGadget is hated by some (Duy, for example, was very\n> vocal about refusing to even look at any of the GitGitGadget-sent patch\n> series, let alone using the tool himself). While I think that this hate is\n> undeserved, I cannot change other people's feelings, nor would I try, all\n> I can do is to try not to make the situation worse.\n> \n> In short: before I spend serious time on extending GitGitGadget to handle\n> git/git PRs, I want to be sure that I won't get backlash for that.\n\nIMHO, GitGitGadget is a useful tool to develop. It has some rough edges,\nstill, but I think the _idea_ is certainly a good one. Especially if the\ndream of bi-directionality is ever fulfilled (though I am not exactly\nholding my breath on that; I think it can get very tricky). But even\nwithout that, I think it's useful to have something like it (or\nsubmitGit) available for some contributors.\n\nIn general, I have not minded the use of GGG on the list lately by you\nor Stolee. I do complain about the rough edges (timestamps, sender-cc on\nthe cover letter, etc), but even as it stands now I am not hating it as\na reviewer. If you are happy with it on the sending side, and especially\nif you want to smooth some of those rough edges, then I do not have a\nproblem myself with its continued use.\n\n-Peff\n"},{"id":"371590","messageId":"nycvar.QRO.7.76.6.1903151427460.41@tvgsbejvaqbjf.bet","threadId":"50722","inReplyTo":"20190315031948.GD28943@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-03-15T13:42:42Z","receivedAt":"2019-03-15T13:43:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Thu, 14 Mar 2019, Jeff King wrote:\n\n> On Thu, Mar 14, 2019 at 12:31:21PM +0100, Johannes Schindelin wrote:\n> \n> > > Hmm. I guess it is still an issue in GGG. This thread has identical\n> > > timestamps on patches 1 and 2 (and my server received them out of order\n> > > by 2 seconds, so mutt orders them wrong):\n> > > \n> > > https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/\n> > > \n> > > I do still think GGG has a more feasible path forward on this particular\n> > > bug, though.\n> > \n> > Indeed. And it is a bug^Wfeature of GMail, I guess, that it knows better\n> > and ignores the Date: header of the mbox fed to it.\n> \n> Heh. So it in fact has the identical problem that submitGit and SES\n> have. :)\n> \n> > The only workaround I can think of is to introduce ugly one-second-sleeps.\n> > I will do that if it proves necessary, but I do have a problem right now\n> > because my only GitGitGadget reviewer (Stolee) is kinda busy with other\n> > things for the time being.\n> \n> I suspect that may be the ultimate solution. Which isn't fantastic, but\n> at the same time, I doubt anybody would really notice that much.\n\nFine, I'll put that on my backlog:\nhttps://github.com/gitgitgadget/gitgitgadget/issues/81\n\n> There are typically delays of seconds to minutes already in delivering\n> email. Unless somebody has a 200 patch series, but maybe then it is\n> kinder to the receivers to let it trickle in. ;)\n\nIndeed. And you remind me: I wanted to disallow annoyingly large patch\nseries: https://github.com/gitgitgadget/gitgitgadget/issues/82\n\nAnother thing that I always dreamed of having: GitGitGadget could\nautomatically warn about commit messages that are incomplete, that\ndisagree with our preferred format, that contain typos or offensive\nlanguage.\n\nLikewise, I had this idea that once we had some robust Clang format\ndefinition, GitGitGadget could verify that the patches conform to what we\nwant, and automatically generate fixed branches if not.\n\nBasically, all the automation I can get, to relieve humans from tasks that\nmachines can do.\n\nChildren can have dreams, can't they ;-)\n\nCiao,\nDscho\n"},{"id":"371593","messageId":"nycvar.QRO.7.76.6.1903151443420.41@tvgsbejvaqbjf.bet","threadId":"50722","inReplyTo":"20190315033020.GE28943@sigill.intra.peff.net","subject":"Re: GitGitGadget on github.com/git/git?, was Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-03-15T14:51:17Z","receivedAt":"2019-03-15T14:51:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Thu, 14 Mar 2019, Jeff King wrote:\n\n> On Thu, Mar 14, 2019 at 01:04:51PM +0100, Johannes Schindelin wrote:\n> \n> > > One thing that I think submitGit can do that GGG cannot (yet), is just\n> > > take PRs straight on git/git. If we're going to start recommending it,\n> > > then I think we'd probably want to configure that, since it's one less\n> > > confusing step for first-timers, who right now might have to go re-make\n> > > their PR on gitgitgadget/git.\n> > \n> > I just realized that I had not responded to that yet. It is not *quite*\n> > that easy, unfortunately.\n> > \n> > I did design GitGitGadget to have a state. For example, to avoid spamming\n> > the Git mailing list with bogus patch series, GitGitGadget maintains a\n> > list of GitHub user names for users allowed to send patch series. (I saw\n> > my share of bogus PRs in the Git for Windows fork, and had no desire to\n> > facilitate similar patch series on the list.) This information, together\n> > with information about the Message IDs to monitor, and about the PRs that\n> > are still open, are maintained in a JSON-formatted object that is stored\n> > in `refs/notes/gitgitgadget`.\n> \n> Ah, I wondered if there might be a catch like this. I do think it would\n> be nice to keep that ref out of git.git. We definitely would not want to\n> lose the features that depend on it, but it sounds like we could use a\n> separate metadata repository.\n\nHow about... brace yourself... https://github.com/gitgitgadget/git?\n\n:-P\n\nSeriously, I still think that the `refs/notes/gitgitgadget` note was a\nrather smart idea, and it was designed to allow for serving multiple\nrepositories. You will note that the PR references in\nhttps://github.com/gitgitgadget/git/blob/1380f7ee9aaf/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391\nare all full URLs, including the GitHub domain and the org. So if any\ncontributor feels strongly enough to support, say, BitBucket or GitLab in\nGitGitGadget, the data structures support that (and I would gladly accept\nPRs for a change).\n\nRead: yes, we could totally extend GitGitGadget in a minimal fashion so\nthat it supports PRs at https://github.com/git/git and stores the relevant\nmetadata in http://github.com/gitgitgadget/git's `gitgitgadget` note,\nstill.\n\n> > I could imagine that we keep pushing those refs to gitgitgadget/git,\n> > but now also allow for PRs on git/git to use GitGitGadget (we would\n> > have to install the GitHub App there, too, and I would have to change\n> > the code to allow that, and we would have to use a slightly different\n> > format for the tags generated from git/git PRs to avoid clashes with\n> > the gitgitgadget/git PRs, all of which is totally doable).\n> \n> I don't think connecting the GitHub App should be a big deal. Ideally it\n> would not even need write permission to the git/git repository, if it's\n> keeping metadata elsewhere (it would need to be able to write PR\n> comments, of course).\n\nWell, bummer. I cannot tell GitHub that it needs a certain permission on\ngit/git vs another permission on gitgitgadget/git.\n\nI guess I'll have to be really diligent about the code base of\nGitGitGadget, then. Or maybe I'll use a second GitHub App that is only\ninstalled on gitgitgadget/git, as a hack.\n\n> It might not be a show-stopper if GitHub's permissions aren't\n> fine-grained enough to allow that, but not having repo write access\n> would be nice insurance against bugs in GitGitGadget writing where we\n> don't expect it to.\n\nRight. Hack it is.\n\n> > If this is truly something we (\"we\" as in \"engaged Git developers\")\n> > want, I can set aside some time to work on that. I had originally\n> > planned on exactly that, i.e. supporting PRs on git/git, but I got\n> > rather strong indications that GitGitGadget is hated by some (Duy, for\n> > example, was very vocal about refusing to even look at any of the\n> > GitGitGadget-sent patch series, let alone using the tool himself).\n> > While I think that this hate is undeserved, I cannot change other\n> > people's feelings, nor would I try, all I can do is to try not to make\n> > the situation worse.\n> > \n> > In short: before I spend serious time on extending GitGitGadget to\n> > handle git/git PRs, I want to be sure that I won't get backlash for\n> > that.\n> \n> IMHO, GitGitGadget is a useful tool to develop. It has some rough edges,\n> still, but I think the _idea_ is certainly a good one. Especially if the\n> dream of bi-directionality is ever fulfilled (though I am not exactly\n> holding my breath on that; I think it can get very tricky). But even\n> without that, I think it's useful to have something like it (or\n> submitGit) available for some contributors.\n\nAgreed.\n\n> In general, I have not minded the use of GGG on the list lately by you\n> or Stolee. I do complain about the rough edges (timestamps, sender-cc on\n> the cover letter, etc), but even as it stands now I am not hating it as\n> a reviewer. If you are happy with it on the sending side, and especially\n> if you want to smooth some of those rough edges, then I do not have a\n> problem myself with its continued use.\n\nWell, Peff, if I had to rank the Git mailing list regulars by \"niceness\",\nyou would be on top. I never doubted that you'd be okay with it.\n\nJunio has been quite a bit more critical of it. And Duy really made a\nstink of it. But yeah, while I really did not feel any love for\nGitGitGadget, I also did not hear more than two voices speaking out\nagainst at least the current state of GitGitGadget.\n\nI'll give others time to chime in before I decide whether I should take\nGitGitGadget into the direction of git/git. (Because, remember, it is not\nquite \"free\", it takes a lot of time out of my schedule.)\n\nFor the time being, I'll of course continue GitGitGadget myself, primarily\nbecause it addresses precisely all of my needs. Which makes sense, because\nthose who develop the software always get the most out of it. It's the way\nit goes.\n\nCiao,\nDscho\n"},{"id":"371614","messageId":"87va0k9k6f.fsf@evledraar.gmail.com","threadId":"50722","inReplyTo":"nycvar.QRO.7.76.6.1903151443420.41@tvgsbejvaqbjf.bet","subject":"Re: GitGitGadget on github.com/git/git?, was Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-03-15T16:28:08Z","receivedAt":"2019-03-15T16:28:14Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Mar 15 2019, Johannes Schindelin wrote:\n\n> Hi Peff,\n>\n> On Thu, 14 Mar 2019, Jeff King wrote:\n>\n>> On Thu, Mar 14, 2019 at 01:04:51PM +0100, Johannes Schindelin wrote:\n>>\n>> > > One thing that I think submitGit can do that GGG cannot (yet), is just\n>> > > take PRs straight on git/git. If we're going to start recommending it,\n>> > > then I think we'd probably want to configure that, since it's one less\n>> > > confusing step for first-timers, who right now might have to go re-make\n>> > > their PR on gitgitgadget/git.\n>> >\n>> > I just realized that I had not responded to that yet. It is not *quite*\n>> > that easy, unfortunately.\n>> >\n>> > I did design GitGitGadget to have a state. For example, to avoid spamming\n>> > the Git mailing list with bogus patch series, GitGitGadget maintains a\n>> > list of GitHub user names for users allowed to send patch series. (I saw\n>> > my share of bogus PRs in the Git for Windows fork, and had no desire to\n>> > facilitate similar patch series on the list.) This information, together\n>> > with information about the Message IDs to monitor, and about the PRs that\n>> > are still open, are maintained in a JSON-formatted object that is stored\n>> > in `refs/notes/gitgitgadget`.\n>>\n>> Ah, I wondered if there might be a catch like this. I do think it would\n>> be nice to keep that ref out of git.git. We definitely would not want to\n>> lose the features that depend on it, but it sounds like we could use a\n>> separate metadata repository.\n>\n> How about... brace yourself... https://github.com/gitgitgadget/git?\n\nFWIW I'd love to see it on git/git for discoverability. From the rest of\nyour E-Mail it sounds like you're working on that. So just a +1.\n\nIf that doesn't work for whatever reason maybe we can amend git.git with\nthis to point people to it:\nhttps://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository\n\nWe have one in .github/PULL_REQUEST_TEMPLATE.md, maybe along with *.txt\ndocs we should amend that, unless of course real GGG on git/git is\nimminent...\n\n> Seriously, I still think that the `refs/notes/gitgitgadget` note was a\n> rather smart idea, and it was designed to allow for serving multiple\n> repositories. You will note that the PR references in\n> https://github.com/gitgitgadget/git/blob/1380f7ee9aaf/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391\n> are all full URLs, including the GitHub domain and the org. So if any\n> contributor feels strongly enough to support, say, BitBucket or GitLab in\n> GitGitGadget, the data structures support that (and I would gladly accept\n> PRs for a change).\n>\n> Read: yes, we could totally extend GitGitGadget in a minimal fashion so\n> that it supports PRs at https://github.com/git/git and stores the relevant\n> metadata in http://github.com/gitgitgadget/git's `gitgitgadget` note,\n> still.\n>\n>> > I could imagine that we keep pushing those refs to gitgitgadget/git,\n>> > but now also allow for PRs on git/git to use GitGitGadget (we would\n>> > have to install the GitHub App there, too, and I would have to change\n>> > the code to allow that, and we would have to use a slightly different\n>> > format for the tags generated from git/git PRs to avoid clashes with\n>> > the gitgitgadget/git PRs, all of which is totally doable).\n>>\n>> I don't think connecting the GitHub App should be a big deal. Ideally it\n>> would not even need write permission to the git/git repository, if it's\n>> keeping metadata elsewhere (it would need to be able to write PR\n>> comments, of course).\n>\n> Well, bummer. I cannot tell GitHub that it needs a certain permission on\n> git/git vs another permission on gitgitgadget/git.\n>\n> I guess I'll have to be really diligent about the code base of\n> GitGitGadget, then. Or maybe I'll use a second GitHub App that is only\n> installed on gitgitgadget/git, as a hack.\n>\n>> It might not be a show-stopper if GitHub's permissions aren't\n>> fine-grained enough to allow that, but not having repo write access\n>> would be nice insurance against bugs in GitGitGadget writing where we\n>> don't expect it to.\n>\n> Right. Hack it is.\n>\n>> > If this is truly something we (\"we\" as in \"engaged Git developers\")\n>> > want, I can set aside some time to work on that. I had originally\n>> > planned on exactly that, i.e. supporting PRs on git/git, but I got\n>> > rather strong indications that GitGitGadget is hated by some (Duy, for\n>> > example, was very vocal about refusing to even look at any of the\n>> > GitGitGadget-sent patch series, let alone using the tool himself).\n>> > While I think that this hate is undeserved, I cannot change other\n>> > people's feelings, nor would I try, all I can do is to try not to make\n>> > the situation worse.\n>> >\n>> > In short: before I spend serious time on extending GitGitGadget to\n>> > handle git/git PRs, I want to be sure that I won't get backlash for\n>> > that.\n>>\n>> IMHO, GitGitGadget is a useful tool to develop. It has some rough edges,\n>> still, but I think the _idea_ is certainly a good one. Especially if the\n>> dream of bi-directionality is ever fulfilled (though I am not exactly\n>> holding my breath on that; I think it can get very tricky). But even\n>> without that, I think it's useful to have something like it (or\n>> submitGit) available for some contributors.\n>\n> Agreed.\n>\n>> In general, I have not minded the use of GGG on the list lately by you\n>> or Stolee. I do complain about the rough edges (timestamps, sender-cc on\n>> the cover letter, etc), but even as it stands now I am not hating it as\n>> a reviewer. If you are happy with it on the sending side, and especially\n>> if you want to smooth some of those rough edges, then I do not have a\n>> problem myself with its continued use.\n>\n> Well, Peff, if I had to rank the Git mailing list regulars by \"niceness\",\n> you would be on top. I never doubted that you'd be okay with it.\n>\n> Junio has been quite a bit more critical of it. And Duy really made a\n> stink of it. But yeah, while I really did not feel any love for\n> GitGitGadget, I also did not hear more than two voices speaking out\n> against at least the current state of GitGitGadget.\n>\n> I'll give others time to chime in before I decide whether I should take\n> GitGitGadget into the direction of git/git. (Because, remember, it is not\n> quite \"free\", it takes a lot of time out of my schedule.)\n>\n> For the time being, I'll of course continue GitGitGadget myself, primarily\n> because it addresses precisely all of my needs. Which makes sense, because\n> those who develop the software always get the most out of it. It's the way\n> it goes.\n\nFWIW my temptations to use it stopped at\nhttps://public-inbox.org/git/nycvar.QRO.7.76.6.1810022234350.2034@tvgsbejvaqbjf.bet/\ni.e. In-Reply-To support.\n\nI've also noticed that for 1/1 patches it sends a 0/1, I don't do that,\nand personally wouldn't want to (just add any comments below \"---\").\n\nBut I'm really happy it's there & useful to people, just not tempted to\nuse it myself because I have a workflow I use already, and from\nobserving it in action I couldn't losslessly move 100% of my submissions\nto it.\n"},{"id":"371618","messageId":"20190315184103.GB4941@sigill.intra.peff.net","threadId":"50722","inReplyTo":"87va0k9k6f.fsf@evledraar.gmail.com","subject":"Re: GitGitGadget on github.com/git/git?, was Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-15T18:41:03Z","receivedAt":"2019-03-15T18:41:06Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 15, 2019 at 05:28:08PM +0100, Ævar Arnfjörð Bjarmason wrote:\n\n> FWIW I'd love to see it on git/git for discoverability. From the rest of\n> your E-Mail it sounds like you're working on that. So just a +1.\n> \n> If that doesn't work for whatever reason maybe we can amend git.git with\n> this to point people to it:\n> https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository\n> \n> We have one in .github/PULL_REQUEST_TEMPLATE.md, maybe along with *.txt\n> docs we should amend that, unless of course real GGG on git/git is\n> imminent...\n\nI think maybe you missed the patch that started this thread, which\nproposes exactly that. :)\n\nIt should point people in the right direction, but of course getting GGG\ndirectly on git/git means that they don't have to re-make their PR on a\ndifferent repo (though I guess they'd see the template while they're\nmaking the PR, and IIRC it's no more difficult at that point than\nclicking the destination repo box at the top of the page?).\n\n> I've also noticed that for 1/1 patches it sends a 0/1, I don't do that,\n> and personally wouldn't want to (just add any comments below \"---\").\n\nThere was some discussion of that elsewhere recently:\n\n https://public-inbox.org/git/20190311202441.GB18263@sigill.intra.peff.net/\n\n> But I'm really happy it's there & useful to people, just not tempted to\n> use it myself because I have a workflow I use already, and from\n> observing it in action I couldn't losslessly move 100% of my submissions\n> to it.\n\nThat's where I'm at, too. I doubt I'd ever use it, because I really like\nmy workflow. But if it is working for other people, especially people\nwho might otherwise be turned off of contributing, that seems like a\ngood thing (as long as the quality of submissions is in the same\nballpark; I think it is, and improving the tooling should keep that\nmoving in the right direction).\n\n-Peff\n"},{"id":"371619","messageId":"20190315184308.GC4941@sigill.intra.peff.net","threadId":"50722","inReplyTo":"nycvar.QRO.7.76.6.1903151427460.41@tvgsbejvaqbjf.bet","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-15T18:43:08Z","receivedAt":"2019-03-15T18:43:11Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 15, 2019 at 02:42:42PM +0100, Johannes Schindelin wrote:\n\n> Another thing that I always dreamed of having: GitGitGadget could\n> automatically warn about commit messages that are incomplete, that\n> disagree with our preferred format, that contain typos or offensive\n> language.\n> \n> Likewise, I had this idea that once we had some robust Clang format\n> definition, GitGitGadget could verify that the patches conform to what we\n> want, and automatically generate fixed branches if not.\n> \n> Basically, all the automation I can get, to relieve humans from tasks that\n> machines can do.\n> \n> Children can have dreams, can't they ;-)\n\nI like all of those dreams. :)\n\nI think the \"checks\" could all just be another form of CI. I think there\nmay be some tricks with automatic rewriting, but it might be possible to\ndo it in the form of GitHub \"suggestions\", which a human could then\nclick \"OK\" to a bunch of them. I guess it would be overwhelming if you\nreally diverged style-wise and the diff is large.\n\nI don't think GitHub has any support for changing commit messages,\nthough, short of your tool force-pushing.\n\n-Peff\n"},{"id":"371766","messageId":"xmqqzhps6ghl.fsf@gitster-ct.c.googlers.com","threadId":"50722","inReplyTo":"20190313201854.GA5530@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-03-18T02:52:54Z","receivedAt":"2019-03-18T02:52:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Hmm. I guess it is still an issue in GGG. This thread has identical\n> timestamps on patches 1 and 2 (and my server received them out of order\n> by 2 seconds, so mutt orders them wrong):\n>\n> https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/\n>\n> I do still think GGG has a more feasible path forward on this particular\n> bug, though.\n\nIf the MSA is rewriting the timestamp (but why? Is the original\ndate \"Wed, 13 Mar 2019 19:20:12 GMT\" malformed or perhaps in the\nfuture or something?), then there isn't much the sending program\ncan---'git send-email' would suffer from the same symptom.\n\n"},{"id":"371843","messageId":"20190318211215.GB29661@sigill.intra.peff.net","threadId":"50722","inReplyTo":"xmqqzhps6ghl.fsf@gitster-ct.c.googlers.com","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-18T21:12:15Z","receivedAt":"2019-03-18T21:12:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 18, 2019 at 11:52:54AM +0900, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Hmm. I guess it is still an issue in GGG. This thread has identical\n> > timestamps on patches 1 and 2 (and my server received them out of order\n> > by 2 seconds, so mutt orders them wrong):\n> >\n> > https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/\n> >\n> > I do still think GGG has a more feasible path forward on this particular\n> > bug, though.\n> \n> If the MSA is rewriting the timestamp (but why? Is the original\n> date \"Wed, 13 Mar 2019 19:20:12 GMT\" malformed or perhaps in the\n> future or something?), then there isn't much the sending program\n> can---'git send-email' would suffer from the same symptom.\n\nI think this statement from me is mid-way through my discovery of the\nactual issue. Yes, if the mail server is rewriting, the best we can do\nis put in an artificial sleep.\n\nIt looks like GitGitGadget just uses normal SMTP to submit the messages.\nI wonder if normal people using gmail as their SMTP server for\nsend-email also suffer from this. I've not ever noticed it, but I\ndon't know how common that setup is.\n\n-Peff\n"},{"id":"371849","messageId":"20190318214842.GA32487@hank.intra.tgummerer.com","threadId":"50722","inReplyTo":"20190318211215.GB29661@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2019-03-18T21:48:42Z","receivedAt":"2019-03-18T21:48:47Z","isPatch":true,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 03/18, Jeff King wrote:\n> On Mon, Mar 18, 2019 at 11:52:54AM +0900, Junio C Hamano wrote:\n> \n> > Jeff King writes:\n> > \n> > > Hmm. I guess it is still an issue in GGG. This thread has identical\n> > > timestamps on patches 1 and 2 (and my server received them out of order\n> > > by 2 seconds, so mutt orders them wrong):\n> > >\n> > > https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/\n> > >\n> > > I do still think GGG has a more feasible path forward on this particular\n> > > bug, though.\n> > \n> > If the MSA is rewriting the timestamp (but why? Is the original\n> > date \"Wed, 13 Mar 2019 19:20:12 GMT\" malformed or perhaps in the\n> > future or something?), then there isn't much the sending program\n> > can---'git send-email' would suffer from the same symptom.\n> \n> I think this statement from me is mid-way through my discovery of the\n> actual issue. Yes, if the mail server is rewriting, the best we can do\n> is put in an artificial sleep.\n> \n> It looks like GitGitGadget just uses normal SMTP to submit the messages.\n> I wonder if normal people using gmail as their SMTP server for\n> send-email also suffer from this. I've not ever noticed it, but I\n> don't know how common that setup is.\n\nI am using gmail as my SMTP server with 'git send-email', and it\ndoesn't look like gmail is rewriting anything there, see [*1*] for\nexample. The date header looks like this:\n\n Date: Mon, 25 Feb 2019 23:16:04 +0000\n\nNote the +0000 there, compared to the GMT that GitGitGadget uses.\nLooking at RFC2822, that's the new version of specifying the timezone,\nwhile GMT is only defined in the obsolete time and date section. I\nguess gmail might just not like that anymore and rewrite it.\n\nSo fixing this might not be that hard, and might not involve sleeping\nwhile sending the patch series at all. Changing how the date is\ncalculated in [*2*] might be all that's needed.\n\n*1*: https://public-inbox.org/git/20190225231631.30507-1-t.gummerer@gmail.com/raw\n*2*: https://github.com/gitgitgadget/gitgitgadget/blob/c37d58cc1581b479892a1f7d29bd16e261676c7d/lib/patch-series.ts#L427\n"},{"id":"371852","messageId":"20190318215233.GI29661@sigill.intra.peff.net","threadId":"50722","inReplyTo":"20190318214842.GA32487@hank.intra.tgummerer.com","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-18T21:52:33Z","receivedAt":"2019-03-18T21:52:37Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 18, 2019 at 09:48:42PM +0000, Thomas Gummerer wrote:\n\n> > It looks like GitGitGadget just uses normal SMTP to submit the messages.\n> > I wonder if normal people using gmail as their SMTP server for\n> > send-email also suffer from this. I've not ever noticed it, but I\n> > don't know how common that setup is.\n> \n> I am using gmail as my SMTP server with 'git send-email', and it\n> doesn't look like gmail is rewriting anything there, see [*1*] for\n> example. The date header looks like this:\n> \n> Date: Mon, 25 Feb 2019 23:16:04 +0000\n> \n> Note the +0000 there, compared to the GMT that GitGitGadget uses.\n> Looking at RFC2822, that's the new version of specifying the timezone,\n> while GMT is only defined in the obsolete time and date section. I\n> guess gmail might just not like that anymore and rewrite it.\n> \n> So fixing this might not be that hard, and might not involve sleeping\n> while sending the patch series at all. Changing how the date is\n> calculated in [*2*] might be all that's needed.\n\nYes, if it really is as simple as just \"gmail doesn't like our date\nformat, so it rewrites the header\", that would be wonderful. Thanks for\nan extra data point.\n\n-Peff\n"},{"id":"371856","messageId":"87h8bzes75.fsf@evledraar.gmail.com","threadId":"50722","inReplyTo":"20190318211215.GB29661@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-03-18T22:25:02Z","receivedAt":"2019-03-18T22:25:07Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Mar 18 2019, Jeff King wrote:\n\n> On Mon, Mar 18, 2019 at 11:52:54AM +0900, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>>\n>> > Hmm. I guess it is still an issue in GGG. This thread has identical\n>> > timestamps on patches 1 and 2 (and my server received them out of order\n>> > by 2 seconds, so mutt orders them wrong):\n>> >\n>> > https://public-inbox.org/git/pull.163.git.gitgitgadget@gmail.com/\n>> >\n>> > I do still think GGG has a more feasible path forward on this particular\n>> > bug, though.\n>>\n>> If the MSA is rewriting the timestamp (but why? Is the original\n>> date \"Wed, 13 Mar 2019 19:20:12 GMT\" malformed or perhaps in the\n>> future or something?), then there isn't much the sending program\n>> can---'git send-email' would suffer from the same symptom.\n>\n> I think this statement from me is mid-way through my discovery of the\n> actual issue. Yes, if the mail server is rewriting, the best we can do\n> is put in an artificial sleep.\n>\n> It looks like GitGitGadget just uses normal SMTP to submit the messages.\n> I wonder if normal people using gmail as their SMTP server for\n> send-email also suffer from this. I've not ever noticed it, but I\n> don't know how common that setup is.\n\nIt's the got-to setup for those of us using gmail & send-email. In\ngit-ml.git:\n\n $ git ls-files | wc -l\n 371333\n $ git grep -l '^\\s+by smtp.gmail.com with ESMTPSA id ' | wc -l\n 35326\n\nRoughly 1/2 of those are patches:\n\n $ git grep --no-line-number -h -C30 '^\\s+by smtp.gmail.com with ESMTPSA id ' |grep \"^Subject: \\[\" | wc -l\n 14567\n"},{"id":"371864","messageId":"xmqq8sxbzowf.fsf@gitster-ct.c.googlers.com","threadId":"50722","inReplyTo":"20190318215233.GI29661@sigill.intra.peff.net","subject":"Re: [RFC/PATCH] point pull requesters to Git Git Gadget","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-03-19T00:30:40Z","receivedAt":"2019-03-19T00:30:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Mar 18, 2019 at 09:48:42PM +0000, Thomas Gummerer wrote:\n>\n>> > It looks like GitGitGadget just uses normal SMTP to submit the messages.\n>> > I wonder if normal people using gmail as their SMTP server for\n>> > send-email also suffer from this. I've not ever noticed it, but I\n>> > don't know how common that setup is.\n>> \n>> I am using gmail as my SMTP server with 'git send-email', and it\n>> doesn't look like gmail is rewriting anything there, see [*1*] for\n>> example. The date header looks like this:\n>> \n>> Date: Mon, 25 Feb 2019 23:16:04 +0000\n>> \n>> Note the +0000 there, compared to the GMT that GitGitGadget uses.\n>> Looking at RFC2822, that's the new version of specifying the timezone,\n>> while GMT is only defined in the obsolete time and date section. I\n>> guess gmail might just not like that anymore and rewrite it.\n>> \n>> So fixing this might not be that hard, and might not involve sleeping\n>> while sending the patch series at all. Changing how the date is\n>> calculated in [*2*] might be all that's needed.\n>\n> Yes, if it really is as simple as just \"gmail doesn't like our date\n> format, so it rewrites the header\", that would be wonderful. Thanks for\n> an extra data point.\n\nI use send-email through SMTP MSA at either gmail or pobox depending\non the phase of the moon, and never noticed an issue with the\ntimestamp we generate. But I noticed the \"GMT\" string in the\n\"original-date\" trail in the problem message, which I didn't think\nwas an timestamp we would generate but somebody else might, and that\nwas why I quoted it in my message. It is good that Thomas noticed\nit, came up with a conjecture and a pointer to a possible fix ;-)\n\nThanks, all.\n\n"}]}