{"thread":{"id":"43864","subject":"Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","startedAt":"2016-08-16T16:55:43Z","lastAt":"2017-02-14T07:13:32Z","messageCount":59,"participants":["Stefan Beller","Junio C Hamano","Jeff King","Eric Wong","Johannes Schindelin","Jakub Narębski","Duy Nguyen","Philip Oakley","Arif Khokar"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"299482","messageId":"CAGZ79kasebzJb=b2n=JQiVMrSfJKaVfZaaoaVJFkXWuqKjfYKw@mail.gmail.com","threadId":"43864","inReplyTo":null,"subject":"Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-08-16T16:55:38Z","receivedAt":"2016-08-16T16:55:43Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"> BTW in light of the discussion we are having elsewhere I just need to\n> point out that it was *dramatically* faster for me to edit run-command.c,\n> find \"hooks/\" and adjust the code manually than it would have been to save\n> the diff and apply it.\n>\n> That's because I do not have advanced tooling on top of email (and I also\n> could not handle mutt, so I am stuck with a not-really-scriptable email\n> client).\n>\n> Just sayin'.\n\nI ran into the same problem, just for a larger patch, so I figured I can\ndownload that from the public inbox and git-am it locally.\nSo I maneuvered to the cover letter of the patch series I am interested in[1]\nand downloaded the series as a mbox.gz[2].\n\nHowever git-am choked on the cover-letter with:\n> Patch is empty. Was it split wrong?\n> When you have resolved this problem, run \"git am --continue\".\n> If you prefer to skip this patch, run \"git am --skip\" instead.\n> To restore the original branch and stop patching, run \"git am --abort\".\n\nThe way forward from here was to `git am --skip` the first mail (the\ncover letter)\nand the rest got applied cleanly.\n\nSo as a discussion starter:\n* Should git am skip a patch 00/XX automatically ?\n It is obviously a cover letter, which may be text only or\n has an intra diff to a prior version. Neither is what we want for now.\n Although there is this other discussion of storing the cover letter,\n so maybe an empty patch that is numbered 0 is fine to skip for now?\n Once the discussion settles whether we want to store it in\n branch..description or as an empty commit at the end or at the beginning\n\n* Should the public-inbox offer another link to patches 1-n, without\n the cover letter? Or should it add instructions:\n\n If this is a patch series you can apply it locally as:\n curl >tmpXXX\n git am tmpXXX && git am --skip && git am --continue\n\nI tend to favor the first option of Git learning how to process the\ncover letter more easily.\n\nThanks,\nStefan\n\n\n[1] https://public-inbox.org/git/20160815230702.30817-1-jacob.e.keller@intel.com/\n[2] https://public-inbox.org/git/20160815230702.30817-1-jacob.e.keller@intel.com/t.mbox.gz\nas found in\n> Thread overview: 4+ messages in thread (expand / mbox.gz / Atom feed / [top])\n> 2016-08-15 23:06 Jacob Keller [this message]\n> 2016-08-15 23:07 ` [PATCH v6 1/3] diff.c: remove output_prefix_length field Jacob Keller\n> 2016-08-15 23:07 ` [PATCH v6 2/3] graph: add support for --line-prefix on all graph-aware output Jacob Keller\n> 2016-08-15 23:07 ` [PATCH v6 3/3] diff: add SUBMODULE_DIFF format to display submodule diff Jacob Keller\n"},{"id":"299484","messageId":"xmqqa8gcej1p.fsf@gitster.mtv.corp.google.com","threadId":"43864","inReplyTo":"CAGZ79kasebzJb=b2n=JQiVMrSfJKaVfZaaoaVJFkXWuqKjfYKw@mail.gmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-16T17:10:42Z","receivedAt":"2016-08-16T17:10:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> So as a discussion starter:\n> * Should git am skip a patch 00/XX automatically ?\n\nNo. My preference is to add \"--initial-skip=\", though.\n\nWhen I receive a patch series to reroll another series, I somehow\nknow and verify that earlier N patches have not changed, I detach\nthe HEAD at the last unchanged commit from the previous round and\napply the remainder of the new series, so that I can preserve the\nauthor timestamps of earlier steps from the previous series. By\nthe time I \"know and verify\" where the first step that was updated,\nI have a full series in a single mbox; having \"--initial-skip=\"\nwould help with that use case, too, and \"skipping the first\" is a\nnarrow special case of giving N=1.\n\n> * Should the public-inbox offer another link to patches 1-n, without\n> the cover letter? Or should it add instructions:\n>\n> If this is a patch series you can apply it locally as:\n> curl >tmpXXX\n> git am tmpXXX && git am --skip && git am --continue\n\nI do not think it is sensible for \"cover-letter\" specific\ninstructions. However, I do not think it is unreasonable to either\nadd another mbox.gz link or replace the behaviour of mbox.gz link so\nthat you can grab a mbox that contains \"this message and everything\nafter it in the thread\". That way, I could open the first message,\nsee something like this I found in your message:\n\n>> Thread overview: 4+ messages in thread (expand / mbox.gz / Atom feed / [top])\n>> 2016-08-15 23:06 Jacob Keller [this message]\n>> 2016-08-15 23:07 ` [PATCH v6 1/3] diff.c: remove output_prefix_length field Jacob Keller\n>> 2016-08-15 23:07 ` [PATCH v6 2/3] graph: add support for --line-prefix on all graph-aware output Jacob Keller\n>> 2016-08-15 23:07 ` [PATCH v6 3/3] diff: add SUBMODULE_DIFF format to display submodule diff Jacob Keller\n\nand then go to 1/3 and click that \"this and everything that\nfollows\".\n"},{"id":"299485","messageId":"20160816172022.juqvfn5vwt2pdcyd@sigill.intra.peff.net","threadId":"43864","inReplyTo":"xmqqa8gcej1p.fsf@gitster.mtv.corp.google.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-16T17:20:22Z","receivedAt":"2016-08-16T17:27:11Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 16, 2016 at 10:10:42AM -0700, Junio C Hamano wrote:\n\n> Stefan Beller writes:\n> \n> > So as a discussion starter:\n> > * Should git am skip a patch 00/XX automatically ?\n> \n> No. My preference is to add \"--initial-skip=\", though.\n> \n> When I receive a patch series to reroll another series, I somehow\n> know and verify that earlier N patches have not changed, I detach\n> the HEAD at the last unchanged commit from the previous round and\n> apply the remainder of the new series, so that I can preserve the\n> author timestamps of earlier steps from the previous series. By\n> the time I \"know and verify\" where the first step that was updated,\n> I have a full series in a single mbox; having \"--initial-skip=\"\n> would help with that use case, too, and \"skipping the first\" is a\n> narrow special case of giving N=1.\n\nFor my workflow, it is not about \"initial skip\", but rather just \"skip\nemails that don't have patches in them at all\". My MUA makes it easy to\ntag a whole thread (or subthread), cover letter and discussion included,\nand then dump it all to git-am.\n\nAnd I think that would be the same for a public-inbox workflow (if it\nlearns to grab sub-threads; otherwise you end up with earlier iterations\nof the series attached to the same thread).\n\nThat is solving a different problem than you, though, where you want to\nskip actual patches because you know they are unchanged.\n\n-Peff\n"},{"id":"299487","messageId":"CAGZ79kby02NuRvQkcuTNjxxc4oDvjAH4wE=3dCXmqyRRrCU0tQ@mail.gmail.com","threadId":"43864","inReplyTo":"xmqqa8gcej1p.fsf@gitster.mtv.corp.google.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-08-16T17:22:57Z","receivedAt":"2016-08-16T17:28:26Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Aug 16, 2016 at 10:10 AM, Junio C Hamano wrote:\n> Stefan Beller writes:\n>\n>> So as a discussion starter:\n>> * Should git am skip a patch 00/XX automatically ?\n>\n> No. My preference is to add \"--initial-skip=\", though.\n>\n> When I receive a patch series to reroll another series, I somehow\n> know and verify that earlier N patches have not changed, I detach\n> the HEAD at the last unchanged commit from the previous round and\n> apply the remainder of the new series, so that I can preserve the\n> author timestamps of earlier steps from the previous series. By\n> the time I \"know and verify\" where the first step that was updated,\n> I have a full series in a single mbox; having \"--initial-skip=\"\n> would help with that use case, too, and \"skipping the first\" is a\n> narrow special case of giving N=1.\n\nIn your work flow, how do you respect the cover letter?\ne.g. in 3787e3c16ced:\n\n Merge branch 'ew/http-backend-batch-headers'\n\n The http-backend (the server-side component of smart-http\n transport) used to trickle the HTTP header one at a time. Now\n these write(2)s are batched.\n\n * ew/http-backend-batch-headers:\n http-backend: buffer headers before sending\n\nIs the text from the original author (and if so from which version\nof the cover letter) or is it your work?\n\n>\n>> * Should the public-inbox offer another link to patches 1-n, without\n>> the cover letter? Or should it add instructions:\n>>\n>> If this is a patch series you can apply it locally as:\n>> curl >tmpXXX\n>> git am tmpXXX && git am --skip && git am --continue\n>\n> I do not think it is sensible for \"cover-letter\" specific\n> instructions. However, I do not think it is unreasonable to either\n> add another mbox.gz link or replace the behaviour of mbox.gz link so\n> that you can grab a mbox that contains \"this message and everything\n> after it in the thread\". That way, I could open the first message,\n> see something like this I found in your message:\n>\n>>> Thread overview: 4+ messages in thread (expand / mbox.gz / Atom feed / [top])\n>>> 2016-08-15 23:06 Jacob Keller [this message]\n>>> 2016-08-15 23:07 ` [PATCH v6 1/3] diff.c: remove output_prefix_length field Jacob Keller\n>>> 2016-08-15 23:07 ` [PATCH v6 2/3] graph: add support for --line-prefix on all graph-aware output Jacob Keller\n>>> 2016-08-15 23:07 ` [PATCH v6 3/3] diff: add SUBMODULE_DIFF format to display submodule diff Jacob Keller\n>\n> and then go to 1/3 and click that \"this and everything that\n> follows\".\n\nBoth thoughts are sensible; However the --initial-skip=\ndoesn't address the special case of storing the cover letter\n(which we eventually want to do?)\n\nI thought of it as the following with room for improvement:\n\ndiff --git a/builtin/am.c b/builtin/am.c (shite space broken):\nindex 739b34d..5f08b61 100644\n--- a/builtin/am.c\n+++ b/builtin/am.c\n@@ -1246,6 +1246,7 @@ static int parse_mail(struct am_state *state,\nconst char *mail)\n FILE *fp;\n struct strbuf sb = STRBUF_INIT;\n struct strbuf msg = STRBUF_INIT;\n+ struct strbuf subject = STRBUF_INIT;\n struct strbuf author_name = STRBUF_INIT;\n struct strbuf author_date = STRBUF_INIT;\n struct strbuf author_email = STRBUF_INIT;\n@@ -1309,6 +1310,7 @@ static int parse_mail(struct am_state *state,\nconst char *mail)\n if (msg.len)\n strbuf_addch(&msg, '\\n');\n strbuf_addstr(&msg, x);\n+ strbuf_addstr(&subject, x);\n } else if (skip_prefix(sb.buf, \"Author: \", &x))\n strbuf_addstr(&author_name, x);\n else if (skip_prefix(sb.buf, \"Email: \", &x))\n@@ -1325,8 +1327,17 @@ static int parse_mail(struct am_state *state,\nconst char *mail)\n }\n\n if (is_empty_file(am_path(state, \"patch\"))) {\n- printf_ln(_(\"Patch is empty. Was it split wrong?\"));\n- die_user_resolve(state);\n+ if (indicates_coverletter(&subject))\n+ /*\n+ * TODO: store the cover letter as the first or last\n+ * commit or as branch..description\n+ */\n+ ret = 1;\n+ goto finish;\n+ else {\n+ printf_ln(_(\"Patch is empty. Was it split wrong?\"));\n+ die_user_resolve(state);\n+ }\n }\n\n strbuf_addstr(&msg, \"\\n\\n\");\n"},{"id":"299489","messageId":"xmqq1t1oehbz.fsf@gitster.mtv.corp.google.com","threadId":"43864","inReplyTo":"CAGZ79kby02NuRvQkcuTNjxxc4oDvjAH4wE=3dCXmqyRRrCU0tQ@mail.gmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-16T17:47:44Z","receivedAt":"2016-08-16T17:50:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> In your work flow, how do you respect the cover letter?\n> e.g. in 3787e3c16ced:\n>\n> Merge branch 'ew/http-backend-batch-headers'\n>\n> The http-backend (the server-side component of smart-http\n> transport) used to trickle the HTTP header one at a time. Now\n> these write(2)s are batched.\n>\n> * ew/http-backend-batch-headers:\n> http-backend: buffer headers before sending\n>\n> Is the text from the original author (and if so from which version\n> of the cover letter) or is it your work?\n\nThe source of truth in the merge log message is the \"What's cooking\"\nreport. I really prefer to write these in my own words, as that is\na good yardstick to measure how much/little I understand the topic.\nIf I cannot describe it concisely, in a way suitable as an entry in\nthe release notes, that means I am merging a topic I do not have a\ngood idea about, which is quite irresponsive. Forcing me to write\nthese myself keeps me honest.\n\nOf course, if a cover letter describes the topic well, it would help\nme write the entry in the \"What's cooking\" report.\n\nIt is a bit tricky to aim for the automation, though. The cover is\nan overview of the proposed log messages and typically tells a story\n\"I do this, and then this, and finally that\", plus a reroll-specific\ncommentary like \"what changed since the last round\". On the other\nhand, the entries in the release notes gives a description of what\nhappened from a third-party's point of view. They are told in\ndifferent voice for different target audience.\n\n\n"},{"id":"299490","messageId":"xmqqtwekd2g6.fsf@gitster.mtv.corp.google.com","threadId":"43864","inReplyTo":"20160816172022.juqvfn5vwt2pdcyd@sigill.intra.peff.net","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-16T17:54:33Z","receivedAt":"2016-08-16T17:54:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> For my workflow, it is not about \"initial skip\", but rather just \"skip\n> emails that don't have patches in them at all\".\n\nOK. That is different from \"the subject line says 0/N so let's\nskip\".\n\nIf we can safely determine that there is no patch in a message,\nskipping it may feel sensible. Historically, we try to err on the\nsafe side by stopping when we do not understand an input and that is\nwhere \"Patch is empty\" message came from, because skipping and\ncontinuing, even with a warning, while applying tons of patches is\nnot good enough to get user's attention.\n\nAn \"ignore empty input\" option (and eventually with a configuration)\nmay not be a bad idea.\n"},{"id":"299507","messageId":"20160816204411.GA31448@dcvr","threadId":"43864","inReplyTo":"xmqqa8gcej1p.fsf@gitster.mtv.corp.google.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-16T20:44:11Z","receivedAt":"2016-08-16T20:44:16Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano wrote:\n> Stefan Beller writes:\n> > * Should the public-inbox offer another link to patches 1-n, without\n> > the cover letter? Or should it add instructions:\n> >\n> > If this is a patch series you can apply it locally as:\n> > curl >tmpXXX\n> > git am tmpXXX && git am --skip && git am --continue\n\nCurrently for web users, I suggest:\n\n\tcurl $URL >tmpXXX\n\n\t# open tmpXXXX and tag+copy to patchesXXX using MUA of choice:\n\t# (also seems to be what Jeff describes):\n\tmutt -f tmpXXX\n\n\tgit am patchesXXXX\n\n> I do not think it is sensible for \"cover-letter\" specific\n> instructions. However, I do not think it is unreasonable to either\n> add another mbox.gz link or replace the behaviour of mbox.gz link so\n> that you can grab a mbox that contains \"this message and everything\n> after it in the thread\". That way, I could open the first message,\n> see something like this I found in your message:\n> \n> >> Thread overview: 4+ messages in thread (expand / mbox.gz / Atom feed / [top])\n> >> 2016-08-15 23:06 Jacob Keller [this message]\n> >> 2016-08-15 23:07 ` [PATCH v6 1/3] diff.c: remove output_prefix_length field Jacob Keller\n> >> 2016-08-15 23:07 ` [PATCH v6 2/3] graph: add support for --line-prefix on all graph-aware output Jacob Keller\n> >> 2016-08-15 23:07 ` [PATCH v6 3/3] diff: add SUBMODULE_DIFF format to display submodule diff Jacob Keller\n> \n> and then go to 1/3 and click that \"this and everything that\n> follows\".\n\nAdding more links might still fall down in cases where\nfixup/squash patches are sent for specific patches in a series;\nor when a v{N+1} series is posted in-reply-to an existing\nseries.\n\nPerhaps adding checkbox next to each item might work as a\nselect-to-include-in-mbox download form. However, I'm already\nfinding the lack of horizontal space disconcerting.\n\nMaybe the YYYY-MM-DD could be shortened to YYYYMMDD. It would\nbe closer to the date searching syntax used by mairix, as well\nas the search enhancement I started working on earlier today:\n\n https://public-inbox.org/meta/20160816084926.29394-1-e@80x24.org/T/\n (still will deploy soonish)\n"},{"id":"299510","messageId":"20160816205636.GA15363@dcvr","threadId":"43864","inReplyTo":"20160816204411.GA31448@dcvr","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-16T20:56:36Z","receivedAt":"2016-08-16T20:56:41Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Eric Wong wrote:\n> Currently for web users, I suggest:\n> \n> \tcurl $URL >tmpXXX\n> \n> \t# open tmpXXXX and tag+copy to patchesXXX using MUA of choice:\n> \t# (also seems to be what Jeff describes):\n> \tmutt -f tmpXXX\n> \n> \tgit am patchesXXXX\n\nI should add this is also a better match to an \"offline first\"\nworkflow for disconnected use. My Internet connections drop\nall the time :<\n\nI don't mind people over-downloading at all, and stuffing an\nextra cover + comments is likely more efficient with gzip than\ngoing back online to fetch separately.\n\n> Perhaps adding checkbox next to each item might work as a\n> select-to-include-in-mbox download form.\n\n...So I'm not sure if I want to invest time into this idea\nsince either the server or user could be offline by the\ntime messages are selected.\n"},{"id":"299600","messageId":"alpine.DEB.2.20.1608181430280.4924@virtualbox","threadId":"43864","inReplyTo":"CAGZ79kasebzJb=b2n=JQiVMrSfJKaVfZaaoaVJFkXWuqKjfYKw@mail.gmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-18T12:42:34Z","receivedAt":"2016-08-18T12:43:47Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Stefan,\n\nOn Tue, 16 Aug 2016, Stefan Beller wrote:\n\n> > BTW in light of the discussion we are having elsewhere I just need to\n> > point out that it was *dramatically* faster for me to edit run-command.c,\n> > find \"hooks/\" and adjust the code manually than it would have been to save\n> > the diff and apply it.\n> >\n> > That's because I do not have advanced tooling on top of email (and I also\n> > could not handle mutt, so I am stuck with a not-really-scriptable email\n> > client).\n> >\n> > Just sayin'.\n> \n> I ran into the same problem, just for a larger patch, so I figured I can\n> download that from the public inbox and git-am it locally.\n> So I maneuvered to the cover letter of the patch series I am interested in[1]\n> and downloaded the series as a mbox.gz[2].\n\nMaybe you can adapt the script I had written to perform that magic for\ngmane?\n\nhttps://github.com/git-for-windows/build-extra/blob/master/apply-from-gmane.sh\n\nThe relevant part is the one between the lines 48--72, where it detects\n0/N mails and then looks for the first children containing k/N for k=1..N.\n\nBTW I take this thread as yet another proof that people are unhappy with\nmail list-based review: if you have to build *that much* tooling around it\n(and Peff & Junio certainly have a megaton of advanced and sophisticated\ntooling around it, holy cow!) it is really incorrect to state that the\nmail list-driven approach works for you. It is much closer to the truth to\nsay that the mail-list-plus-loads-of-custom-tools-driven approach works\nfor you.\n\nI am really not a fan of this.\n\nThe theory \"it's inclusive because everyone has access to mail\" falls on\nits face, badly, when even old timers have to build entire infrastructures\naround it just to begin to be able to use it efficiently.\n\nIt reminds me of an old software developer I met long ago, who claimed CVS\nworks for him. He had written tens of thousands of lines of shell scripts,\nis what allowed \"CVS\" to work for him.\n\nSame here. Old dogs claim the mail list-approach works for them. Nope.\nDoesn't. Else you would not have written all those custom scripts.\n\nCiao,\nDscho\n"},{"id":"299648","messageId":"xmqqzio94uw8.fsf@gitster.mtv.corp.google.com","threadId":"43864","inReplyTo":"20160818204902.GA1670@starla","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-18T21:41:43Z","receivedAt":"2016-08-19T01:16:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong writes:\n\n> I see a choice of mail client as no different than a choice of\n> text editor. Neither my mail client or text editor is heavily\n> customized. The key feature I rely on from both tools is piping\n> data to external commands.\n\nFWIW, that applies to me exactly, too.\n\n> unsubscribe: meta+unsubscribe@public-inbox.org\n\nDid you mean this, really?\n\n> archive: https://public-inbox.org/meta/\n\nThis I understand, though.\n\nAhh, that's coming from meta@public-inbox.org?\n"},{"id":"299653","messageId":"20160818204902.GA1670@starla","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608181430280.4924@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-18T20:49:02Z","receivedAt":"2016-08-19T01:34:23Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> BTW I take this thread as yet another proof that people are unhappy with\n> mail list-based review: if you have to build *that much* tooling around it\n> (and Peff & Junio certainly have a megaton of advanced and sophisticated\n> tooling around it, holy cow!) it is really incorrect to state that the\n> mail list-driven approach works for you. It is much closer to the truth to\n> say that the mail-list-plus-loads-of-custom-tools-driven approach works\n> for you.\n> \n> I am really not a fan of this.\n> \n> The theory \"it's inclusive because everyone has access to mail\" falls on\n> its face, badly, when even old timers have to build entire infrastructures\n> around it just to begin to be able to use it efficiently.\n> \n> It reminds me of an old software developer I met long ago, who claimed CVS\n> works for him. He had written tens of thousands of lines of shell scripts,\n> is what allowed \"CVS\" to work for him.\n> \n> Same here. Old dogs claim the mail list-approach works for them. Nope.\n> Doesn't. Else you would not have written all those custom scripts.\n\ngit and cogito started as a bunch of custom scripts, too.\nIMHO, it's what makes Free Software (and *nix) great:\nusers have control to customize and improve things.\nWith scripts, they don't even need to learn a build process\nto do so.\n\nI see a choice of mail client as no different than a choice of\ntext editor. Neither my mail client or text editor is heavily\ncustomized. The key feature I rely on from both tools is piping\ndata to external commands.\n\n\nOTOH, today, I see people using git aliases all the time which\nlook more like ASM instructions than user commands.\n\nIs the widespread use of these aliases a deficiency to git?\nMaybe, I don't know.\n\nNormally, I do not care about aliases: it's a private thing;\nbut it also makes it incredibly difficult for me to help\nusers when they're exposed in public.\n\n\nUsers ought to be able to pick, choose, and replace tools as\nthey wish as long as an interchange format remains stable\nand widely-supported.\n\nFwiw, I still use patch(1) pretty often, even on patches\ngenerated with git. I see nothing wrong with that; patch is\nlenient in ways git-apply was explicitly designed not to be.\nAnd I don't always use git send-email or my normal MUA for\nsending; or use git for generating diffs. I do:\n\n\tdiff -u a b | mail -s WIP-blah-blah $SOMEONE\n\n\nWhile you and I are long-time git hackers, I don't think it's\nreasonable for everyone to use git or git-specific tools;\neven to git.git for one-offs like portability or doc fixes.\n\nEven today, at least one Linux kernel hacker still uses quilt to\ngenerate patches: http://ozlabs.org/~akpm/mmotm/\n"},{"id":"299707","messageId":"20160819150340.725bejnps6474u2e@sigill.intra.peff.net","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608181430280.4924@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-19T15:03:40Z","receivedAt":"2016-08-19T15:05:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 18, 2016 at 02:42:34PM +0200, Johannes Schindelin wrote:\n\n> BTW I take this thread as yet another proof that people are unhappy with\n> mail list-based review: if you have to build *that much* tooling around it\n> (and Peff & Junio certainly have a megaton of advanced and sophisticated\n> tooling around it, holy cow!) it is really incorrect to state that the\n> mail list-driven approach works for you. It is much closer to the truth to\n> say that the mail-list-plus-loads-of-custom-tools-driven approach works\n> for you.\n> \n> I am really not a fan of this.\n> \n> The theory \"it's inclusive because everyone has access to mail\" falls on\n> its face, badly, when even old timers have to build entire infrastructures\n> around it just to begin to be able to use it efficiently.\n> \n> It reminds me of an old software developer I met long ago, who claimed CVS\n> works for him. He had written tens of thousands of lines of shell scripts,\n> is what allowed \"CVS\" to work for him.\n> \n> Same here. Old dogs claim the mail list-approach works for them. Nope.\n> Doesn't. Else you would not have written all those custom scripts.\n\nI read this over, didn't agree, waited a whole day for perspective, and\nstill just can't agree. So now I'm responding. :)\n\nThere is nothing wrong with building tooling around your workflow. If we\nhad a GitHub-based workflow, I'd build tooling around that, too. One of\nthe things I _like_ about a mail-based workflow is how easy it is to\nbuild that tooling, and to get it to integrate with other existing\ntools. It's the major reason I'm resistant to moving development to\nGitHub. Not only would I have to throw away all of my tools, but I'm not\nsure I could easily build equivalent ones.\n\nNow, I am perfectly open to the idea that more of the tooling should be\nstandardized, so people do not have to build their own. But the major\nproblem there is that so much of what I've built is about gluing things\ntogether for the rest of _my_ tools. I've shared my techniques and\nscripts for using mutt several times, but they don't do somebody a lick\nof good if they are using gmail or thunderbird.\n\nSo I don't really think I have a megaton of tooling. I just have a\nlittle bit of glue to existing tools I was using anyway. And I think\nthat is where the disconnect is. If you are not using mutt already, then\nit sure seems like a big jump to change your MUA. And I'm sympathetic to\nthat. But I don't think that means that the mailing-list approach is not\nworking for me, as you claim in the last paragraph.\n\n-Peff\n\nPS There _are_ some open questions in our workflow that are not really\n mailing list specific. E.g., the fact that it is hard to see whether\n and if your patch was picked up by Junio, what changes were made,\n tracking multiple versions, etc. I _don't_ have good tooling for\n that, but it's something that could be made generally available, as\n it's unrelated to the MUA. It's also not necessarily specific to\n mailing list development (e.g., a push-based workflow that\n aggressively rebases runs into the same versioning questions).\n"},{"id":"299710","messageId":"alpine.DEB.2.20.1608191717490.4924@virtualbox","threadId":"43864","inReplyTo":"xmqqzio94uw8.fsf@gitster.mtv.corp.google.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-19T15:18:13Z","receivedAt":"2016-08-19T15:18:34Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 18 Aug 2016, Junio C Hamano wrote:\n\n> Eric Wong writes:\n> \n> > unsubscribe: meta+unsubscribe@public-inbox.org\n> \n> Did you mean this, really?\n\nFWIW I do not see this line in my original mail from Eric.\n\nCiao,\nDscho\n"},{"id":"299711","messageId":"alpine.DEB.2.20.1608191720040.4924@virtualbox","threadId":"43864","inReplyTo":"20160818204902.GA1670@starla","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-19T15:30:14Z","receivedAt":"2016-08-19T15:30:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Eric,\n\nOn Thu, 18 Aug 2016, Eric Wong wrote:\n\n> Johannes Schindelin wrote:\n>\n> > Old dogs claim the mail list-approach works for them. Nope. Doesn't.\n> > Else you would not have written all those custom scripts.\n> \n> git and cogito started as a bunch of custom scripts, too.\n\nThe difference is that neither git nor cogito were opinionated. Those\ncustom scripts are. They are for one particular workflow, with one\nparticular mail client, with a strong bias to a Unix-y environment.\n\nI work really hard to make Git for Windows as easy and fun to use as\npossible. I just wish that we were working together to make it as easy and\nfun to contribute to Git, too.\n\n> I see a choice of mail client as no different than a choice of\n> text editor. Neither my mail client or text editor is heavily\n> customized. The key feature I rely on from both tools is piping\n> data to external commands.\n\nThere you go. That key feature seems to be unavailable in the most\nwide-spread email client: Outlook. So by not restricting the choice you\nshould make it possible to use that mail client, too, right?\n\nWe do not even have a section on Outlook in our SubmittingPatches.\n\nOkay, if not the most popular mail client, then web mail? Nope, nope,\nnope. No piping *at all* to external commands from there.\n\nSo you basically slam the door shut on the vast majority of email users.\n\nThat is not leaving much choice to the users in my book.\n\n> OTOH, today, I see people using git aliases all the time which\n> look more like ASM instructions than user commands.\n\nI see this as a completely different beast. Aliases help users accelerate\ntheir personal workflow. Whereas anybody who is already willing to\ncontribute to Git *must* go through that non-personal workflow we impose:\npaste the diff in a very specific format into the mail, and don't you dare\nuse a mail client that mangles whitespace (which is, like, pretty much\nevery single popular mail client out there).\n\nSo *allowing* users to configure their own aliases, and *forcing* them to\nfigure out how to transport patches through a medium hostile to patches,\nis pretty much two diametrically opposed things.\n\n> Users ought to be able to pick, choose, and replace tools as\n> they wish as long as an interchange format remains stable\n> and widely-supported.\n\nRight. Let's talk about the interchange format called mails, for the data\ncalled patches. Is it stable and widely-supported?\n\nCan users really pick and choose the tools they like most to send patches\nto the Git project? Like, the Outlook client? Or the GMail client?\n\n> Even today, at least one Linux kernel hacker still uses quilt to\n> generate patches: http://ozlabs.org/~akpm/mmotm/\n\nAndrew does not count, he lives in his own universe.\n\nCiao,\nDscho\n"},{"id":"299719","messageId":"CAGZ79kb9x6RHdFeA8WXpq4NFYr-G+B1R7_8u883LO8zvPyr+CQ@mail.gmail.com","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608191720040.4924@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-08-19T16:55:54Z","receivedAt":"2016-08-19T16:56:46Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"It was not my intend to start this discussion again with my initial email.\nI rather wanted to point out how I make progress in doing my own\ntooling.\n\nI mean if email works well for Junio (both as a maintainer as\nwell as a contributor) and Jeff as a contributor, then I can adapt\nmy workflow to that, because these two have brought in\n8300 of 33000 non merge patches. (i.e. they had 25% of the\npatches over the life time of the project and are with the project\nlonger than others IIUC). So why would I demand they change\ntheir style just to accommodate one newcomer like me?\n\n>\n>> I see a choice of mail client as no different than a choice of\n>> text editor. Neither my mail client or text editor is heavily\n>> customized. The key feature I rely on from both tools is piping\n>> data to external commands.\n>\n> There you go. That key feature seems to be unavailable in the most\n> wide-spread email client: Outlook. So by not restricting the choice you\n> should make it possible to use that mail client, too, right?\n\nWell I think this data piping is essential to any workflow. Even if were to\nabandon email completely and roll our own communications protocol,\none of the first things added would be an API to \"use your own text editor\".\n\nIn my case git-send-email works well for the sending direction without a lot\nof custom tooling (read: none apart from the initial configuration).\n\n>\n> We do not even have a section on Outlook in our SubmittingPatches.\n\n\"You can write one? Pretty please?\"\nwould be the canonical answer. ;)\n\n>\n> Okay, if not the most popular mail client, then web mail? Nope, nope,\n> nope. No piping *at all* to external commands from there.\n>\n> So you basically slam the door shut on the vast majority of email users.\n>\n> That is not leaving much choice to the users in my book.\n>\n>> OTOH, today, I see people using git aliases all the time which\n>> look more like ASM instructions than user commands.\n>\n> I see this as a completely different beast. Aliases help users accelerate\n> their personal workflow. Whereas anybody who is already willing to\n> contribute to Git *must* go through that non-personal workflow we impose:\n> paste the diff in a very specific format into the mail, and don't you dare\n> use a mail client that mangles whitespace (which is, like, pretty much\n> every single popular mail client out there).\n\nMaybe we should invent a patch format that copes with broken whitespace?\n(git-format-patch --allow-broken-whitespace), e.g. replace a tab by\n\"-_______\" (not exactly 8 chars, but stopping at the columns 8, 16, 24 etc)\ngit am/apply would need to know about the unbreaking the white space, too.\n\n>\n> So *allowing* users to configure their own aliases, and *forcing* them to\n> figure out how to transport patches through a medium hostile to patches,\n> is pretty much two diametrically opposed things.\n\nI think the point was that people carelessly expose their aliases in e.g. their\nblogs. (e.g. \"to do you just need to git a &&git ci &&\ngit rr\", which\nleaves others just guessing? It certainly feels similar to not knowing how to\nconfigure your email client?)\n\n>\n>> Users ought to be able to pick, choose, and replace tools as\n>> they wish as long as an interchange format remains stable\n>> and widely-supported.\n>\n> Right. Let's talk about the interchange format called mails, for the data\n> called patches. Is it stable and widely-supported?\n\nIt is stable as it has been around for years and you can choose whether you\nuse git apply or the patch utility. It is widely supported as it is raw text so\nit can be used across different platforms. However it doesn't cope well with\nemail, as email modifies text sometimes such as mangling white spaces.\n\n>\n> Can users really pick and choose the tools they like most to send patches\n> to the Git project? Like, the Outlook client? Or the GMail client?\n\nOf course, see[1] ;)\n[1] https://public-inbox.org/git/CA+55aFy2AEe7ew5Px=2Uit6hraGV9zFr=JZ57rSYXWMQ4nMjeg@mail.gmail.com/\n\nThanks,\nStefan\n"},{"id":"299769","messageId":"20160819223532.GA19084@starla","threadId":"43864","inReplyTo":"CAGZ79kb9x6RHdFeA8WXpq4NFYr-G+B1R7_8u883LO8zvPyr+CQ@mail.gmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-19T22:35:32Z","receivedAt":"2016-08-19T22:35:37Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Stefan Beller wrote:\n> Maybe we should invent a patch format that copes with broken whitespace?\n\nNo redundant new formats, please. MIME attachments are already\nwidely-supported and fine by me. But it's not my call for git.\n"},{"id":"299770","messageId":"20160819223547.GB16646@dcvr","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608191720040.4924@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-19T22:35:47Z","receivedAt":"2016-08-19T22:35:52Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> On Thu, 18 Aug 2016, Eric Wong wrote:\n> > Johannes Schindelin wrote:\n> >\n> > > Old dogs claim the mail list-approach works for them. Nope. Doesn't.\n> > > Else you would not have written all those custom scripts.\n> > \n> > git and cogito started as a bunch of custom scripts, too.\n> \n> The difference is that neither git nor cogito were opinionated. Those\n> custom scripts are. They are for one particular workflow, with one\n> particular mail client, with a strong bias to a Unix-y environment.\n> \n> I work really hard to make Git for Windows as easy and fun to use as\n> possible. I just wish that we were working together to make it as easy and\n> fun to contribute to Git, too.\n\nI guess this is a fundamental difference between *nix and\nWindows culture.\n\nI enjoy using and contributing to git because it interacts well\nwith generic tools. *nix kernels are optimized for this with\ndecent (not great)[*] process spawning and IPC performance.\n\nI know Windows users have major performance problems with\nshell scripts; but they are also largely helpless to improve\nWindows kernel performance.\n\nSo, I guess monolithic tools became popular on Windows, instead.\n\n> > I see a choice of mail client as no different than a choice of\n> > text editor. Neither my mail client or text editor is heavily\n> > customized. The key feature I rely on from both tools is piping\n> > data to external commands.\n> \n> There you go. That key feature seems to be unavailable in the most\n> wide-spread email client: Outlook. So by not restricting the choice you\n> should make it possible to use that mail client, too, right?\n> \n> We do not even have a section on Outlook in our SubmittingPatches.\n> \n> Okay, if not the most popular mail client, then web mail? Nope, nope,\n> nope. No piping *at all* to external commands from there.\n> \n> So you basically slam the door shut on the vast majority of email users.\n\nUsers have a choice to use a more scriptable mail client\n(but I guess the OS nudges users towards monolithic tools)\n\nIt's unfortunate the world is so full of proprietary things;\nbut I think it's our responsibility as Free Software developers\nto encourage the use of Free (or \"Open Source\") tools which\nusers can control.\n\n> That is not leaving much choice to the users in my book.\n\nUsers of alpine, gnus, mutt, sylpheed, thunderbird, kmail,\nroundcube, squirelmail, etc. can all download the source, hack,\nfix and customize things. It's easier with smaller software,\nof course: git-send-email does not even require learning\nthe build process or separate download.\n\n\n\n> > Users ought to be able to pick, choose, and replace tools as\n> > they wish as long as an interchange format remains stable\n> > and widely-supported.\n> \n> Right. Let's talk about the interchange format called mails, for the data\n> called patches. Is it stable and widely-supported?\n> \n> Can users really pick and choose the tools they like most to send patches\n> to the Git project? Like, the Outlook client? Or the GMail client?\n\nPersonally, I don't mind patches as MIME attachments if that\navoids corruption, MIME seems well-supported at this point.\nIt's not my call, though. But as Stephan pointed, Linus\ndoes it, too.\n\n\n\n[*] Guess what: I have performance problems with fork/execve on\n Linux, too. However, Linux developers already provide\n mechanisms to improve spawn performance (CLONE_VFORK and\n vfork(2)); so the next step is to get userspace like dash,\n make, perl, etc to support these.\n\n glibc 2.24 was just released with an improved posix_spawn\n for Linux (using CLONE_VFORK), so that's a step forward and\n might make sharing code with Windows easier, too.\n\n It's not a high priority for me at the moment, but I intend\n to get everything in my toolset which relies on fork+execve\n to use posix_spawn or vfork+execve instead. I have the\n source to all of these, so at least I can do something\n about it.\n"},{"id":"299799","messageId":"46a5b9b6-f3f6-7650-8a5b-b0b52223e375@gmail.com","threadId":"43864","inReplyTo":"20160819150340.725bejnps6474u2e@sigill.intra.peff.net","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-08-20T19:57:46Z","receivedAt":"2016-08-20T19:58:17Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 19.08.2016 o 17:03, Jeff King pisze:\n[...]\n \n> There is nothing wrong with building tooling around your workflow. If we\n> had a GitHub-based workflow, I'd build tooling around that, too. One of\n> the things I _like_ about a mail-based workflow is how easy it is to\n> build that tooling, and to get it to integrate with other existing\n> tools. It's the major reason I'm resistant to moving development to\n> GitHub. Not only would I have to throw away all of my tools, but I'm not\n> sure I could easily build equivalent ones.\n\nAlso, you would have the same problem with tooling around specific Git\nhosting site as there is with tooling around specific email client.\nTool that works with GitHub (like submitGit) won't work with Bitbucket\nor GitLab.\n\nWell, unless such tooling was built in in all hosting sites. They have\nsupport for sending mails anyway, isn't it?\n\nBut perhaps the problem is current lack of tooling in the opposite direction,\nnamely getting patches from mailing list and applying them to GitHub repo,\nor Bitbucket, or GitLab. Though with working Git, it is something easier\nthan sending patches via email; it is enough that email client can save\nemail to a file (or better, whole sub-thread to file or files).\n\nAlso, there is lack of tools that convert inline (in-diff) comments on\nGitHub (or Bitbucket, or GitLab) to email with review...\n\n\nThere is also distrust for centralized solutions (email is, in principle,\ndecentralized). See projects like https://solid.mit.edu, etc.\n\n> Now, I am perfectly open to the idea that more of the tooling should be\n> standardized, so people do not have to build their own. But the major\n> problem there is that so much of what I've built is about gluing things\n> together for the rest of _my_ tools. I've shared my techniques and\n> scripts for using mutt several times, but they don't do somebody a lick\n> of good if they are using gmail or thunderbird.\n\nIt would be nice to have links to those tools in SubmittingPatches and/or\nthe Git homepage.\n\n[...] \n> PS There _are_ some open questions in our workflow that are not really\n> mailing list specific. E.g., the fact that it is hard to see whether\n> and if your patch was picked up by Junio, what changes were made,\n> tracking multiple versions, etc. I _don't_ have good tooling for\n> that, but it's something that could be made generally available, as\n> it's unrelated to the MUA. It's also not necessarily specific to\n> mailing list development (e.g., a push-based workflow that\n> aggressively rebases runs into the same versioning questions).\n\nWell, \"What's cooking ...\" and 'pu' branch helps, I think.\n\n-- \nJakub Narębski\n\n"},{"id":"299844","messageId":"alpine.DEB.2.20.1608221450250.4924@virtualbox","threadId":"43864","inReplyTo":"20160819150340.725bejnps6474u2e@sigill.intra.peff.net","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-22T13:06:14Z","receivedAt":"2016-08-22T13:06:33Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Fri, 19 Aug 2016, Jeff King wrote:\n\n> On Thu, Aug 18, 2016 at 02:42:34PM +0200, Johannes Schindelin wrote:\n> \n> > BTW I take this thread as yet another proof that people are unhappy\n> > with mail list-based review: if you have to build *that much* tooling\n> > around it (and Peff & Junio certainly have a megaton of advanced and\n> > sophisticated tooling around it, holy cow!) it is really incorrect to\n> > state that the mail list-driven approach works for you. It is much\n> > closer to the truth to say that the\n> > mail-list-plus-loads-of-custom-tools-driven approach works for you.\n> > \n> > I am really not a fan of this.\n> > \n> > The theory \"it's inclusive because everyone has access to mail\" falls\n> > on its face, badly, when even old timers have to build entire\n> > infrastructures around it just to begin to be able to use it\n> > efficiently.\n> > \n> > It reminds me of an old software developer I met long ago, who claimed\n> > CVS works for him. He had written tens of thousands of lines of shell\n> > scripts, is what allowed \"CVS\" to work for him.\n> > \n> > Same here. Old dogs claim the mail list-approach works for them. Nope.\n> > Doesn't. Else you would not have written all those custom scripts.\n> \n> I read this over, didn't agree, waited a whole day for perspective, and\n> still just can't agree. So now I'm responding. :)\n\nThank you for your constructive feedback.\n\nObviously I just can't agree with what you wrote, at least not completely.\nSo after waiting an entire weekend for perspective, here are my thoughts\non your comments:\n\n> There is nothing wrong with building tooling around your workflow. If we\n> had a GitHub-based workflow, I'd build tooling around that, too.\n\nSure. You, Junio and myself seem to be kings of scripting. Automating\ncommon tasks through scripting is something that allows me to not go\ncompletely bunkers with the workload I have. I imagine it is similar on\nyour side.\n\n> One of the things I _like_ about a mail-based workflow is how easy it is\n> to build that tooling, and to get it to integrate with other existing\n> tools.\n\nHere I disagree violently. What I would have agreed to would be a\nstatement similar to \"It is easy to integrate scripting with mutt\".\n\nTo be quite frank: we are talking about very different things when we talk\nabout mail-based workflows. Heck, we even talk about gazillions of\ndifferent things when we talk about an email! Just think about this here\nemail: you might read it written in a font that makes it easy to discern\n\"1\" from \"l\" from \"I\". For a vast number of people, this is not even true!\n\nSo what we are talking about here are apples and oranges and apple cider\nvinegar. Email clients are *so vastly different* from one another, it\nwould be ludicrious to assume that they have anything in common when it\ncomes to \"mail-based workflows\".\n\nAs a matter of fact, the thing that you pointed out as the most important\n(\"how easy it is [...] to integrate with other existing tools\") does *not*\napply for the *vast* majority of email clients, most prominently Outlook,\nGMail, Apple Mail and Thunderbird.\n\nAnd that mere fact is very, very important to keep in mind. We build Git,\nwhich is very, very successful because it fills a need of developers using\nmeans that are accessible to many, directly or indirectly (the\ncommand-line).\n\nYet, when it comes to contributing to Git's source code, we deviate from\nthe common path and require a means that is *not* accessible to many. We\nrequire them to use something different than their regular email client.\n\n> It's the major reason I'm resistant to moving development to GitHub. Not\n> only would I have to throw away all of my tools, but I'm not sure I\n> could easily build equivalent ones.\n\nI am sympathetic to your reasoning (even if I vividly disagree with your\nassessment that it would be difficult to build tools around the GitHub\nAPI, I made quite a couple of such tools myself, and it is quite easy, you\ncan even script it on the command-line using cURL).\n\nHowever, I have to point out that the Git project is really uninviting to\ncontributors, and that this resistance is part of what makes it so.\n\n> Now, I am perfectly open to the idea that more of the tooling should be\n> standardized, so people do not have to build their own. But the major\n> problem there is that so much of what I've built is about gluing things\n> together for the rest of _my_ tools. I've shared my techniques and\n> scripts for using mutt several times, but they don't do somebody a lick\n> of good if they are using gmail or thunderbird.\n\nIt is nice of you to share those tools, of course, and you are correct\nthat the specificity of your tools limits their being useful. I, for one,\ncannot use your mutt-based tools.\n\n(I gladly use git-jump now, though, but it is still very limited by its\nbeing specific to vim. In other words, both your mutt-based scripts and\nyour git-jump script are limited in their audience just by being so\nopinionated. This is distinctly different from Git's being unopinionated.)\n\n> So I don't really think I have a megaton of tooling. I just have a\n> little bit of glue to existing tools I was using anyway.\n\nThose existing tools are part of that megaton. For the purpose of my\nargument, they contribute as much to the barrier of entry to contribute\neasily to Git's source code as anything else in the mail-based workflow.\n\n> And I think that is where the disconnect is. If you are not using mutt\n> already, then it sure seems like a big jump to change your MUA. And I'm\n> sympathetic to that. But I don't think that means that the mailing-list\n> approach is not working for me, as you claim in the last paragraph.\n\nOkay, let's call it the mailing-list-plus-mutt-plus-glue approach, then.\n\nMy point stands. We are way more uninviting to contributors than\nnecessary. And a huge part of the problem is that we require contributors\nto send their patches inlined into whitespace-preserving mails.\n\nPersonally, I think we can do much better than that.\n\nCiao,\nDscho\n"},{"id":"299846","messageId":"CACsJy8BG63oaLbw0f7try3OpzdphLC7UGAaJ=vgikEB36Pagqg@mail.gmail.com","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608221450250.4924@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-08-22T13:15:49Z","receivedAt":"2016-08-22T13:16:45Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Aug 22, 2016 at 8:06 PM, Johannes Schindelin\n wrote:\n> My point stands. We are way more uninviting to contributors than\n> necessary. And a huge part of the problem is that we require contributors\n> to send their patches inlined into whitespace-preserving mails.\n\nWe probably can settle this in the next git survey with a new\nquestion: what's stopping you from contributing to git?\n-- \nDuy\n"},{"id":"299848","messageId":"alpine.DEB.2.20.1608221509010.4924@virtualbox","threadId":"43864","inReplyTo":"20160819223547.GB16646@dcvr","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-22T13:18:03Z","receivedAt":"2016-08-22T13:24:50Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Eric,\n\nOn Fri, 19 Aug 2016, Eric Wong wrote:\n\n> Johannes Schindelin wrote:\n> > On Thu, 18 Aug 2016, Eric Wong wrote:\n> > > Johannes Schindelin wrote:\n> > >\n> > > > Old dogs claim the mail list-approach works for them. Nope.\n> > > > Doesn't. Else you would not have written all those custom\n> > > > scripts.\n> > > \n> > > git and cogito started as a bunch of custom scripts, too.\n> > \n> > The difference is that neither git nor cogito were opinionated. Those\n> > custom scripts are. They are for one particular workflow, with one\n> > particular mail client, with a strong bias to a Unix-y environment.\n> > \n> > I work really hard to make Git for Windows as easy and fun to use as\n> > possible. I just wish that we were working together to make it as easy\n> > and fun to contribute to Git, too.\n> \n> I guess this is a fundamental difference between *nix and Windows\n> culture.\n\nI do not understand how you get from \"I wish to make it fun to contribute\nto Git\" to \"there is a fundamental difference between *nix and Windows\nculture\".\n\n> I know Windows users have major performance problems with\n> shell scripts;\n\nThat's because shell scripting is not native to Windows. I wish Linux had\na Powershell, allowing for decent scripting that does not try to smoosh\neverything into a line-based text format. (Of course, since last week,\nLinux does have a Powershell.)\n\nPowershell is blazing fast, by the way, and not as ridiculously limited in\nits expressibility as shell scripting.\n\nBut all of this is digressing from the original topic. I do not think this\nis a productive.\n\n> > We do not even have a section on Outlook in our SubmittingPatches.\n> > \n> > Okay, if not the most popular mail client, then web mail? Nope, nope,\n> > nope. No piping *at all* to external commands from there.\n> > \n> > So you basically slam the door shut on the vast majority of email users.\n> \n> Users have a choice to use a more scriptable mail client\n> (but I guess the OS nudges users towards monolithic tools)\n\nYou call that choice. Are you serious?\n\n> > That is not leaving much choice to the users in my book.\n> \n> Users of alpine, gnus, mutt, sylpheed, thunderbird, kmail,\n> roundcube, squirelmail, etc. can all download the source, hack,\n> fix and customize things. It's easier with smaller software,\n> of course: git-send-email does not even require learning\n> the build process or separate download.\n\nNow I am getting upset. This is a BS argument. Sure, I can hack the source\nof these tools.\n\nBut why on earth do I *have* to? Why can't we use or create an open\ncontribution process *that works without having to work so hard to be able\nto contribute*?\n\nSo unfortunately this thread has devolved. Which is sad. Because all I\nwanted is to have a change in Git's submission process that would not\nexclude *so many* developers. That is really all I care about. Not about\ntools. Not about open vs proprietary, or standards.\n\nI just want developers who are already familiar with Git, and come up with\nan improvement to Git itself, to be able to contribute it without having\nto pull out their hair in despair.\n\nCiao,\nDscho\n"},{"id":"299850","messageId":"alpine.DEB.2.20.1608221523130.4924@virtualbox","threadId":"43864","inReplyTo":"CAGZ79kb9x6RHdFeA8WXpq4NFYr-G+B1R7_8u883LO8zvPyr+CQ@mail.gmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-22T13:38:51Z","receivedAt":"2016-08-22T13:44:21Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Stefan,\n\nOn Fri, 19 Aug 2016, Stefan Beller wrote:\n\n> >> I see a choice of mail client as no different than a choice of text\n> >> editor. Neither my mail client or text editor is heavily customized.\n> >> The key feature I rely on from both tools is piping data to external\n> >> commands.\n> >\n> > There you go. That key feature seems to be unavailable in the most\n> > wide-spread email client: Outlook. So by not restricting the choice\n> > you should make it possible to use that mail client, too, right?\n> \n> Well I think this data piping is essential to any workflow.\n\nData piping can go through Git, with convenient commands.\n\n> Even if were to abandon email completely and roll our own communications\n> protocol, one of the first things added would be an API to \"use your own\n> text editor\".\n> \n> In my case git-send-email works well for the sending direction without a\n> lot of custom tooling (read: none apart from the initial configuration).\n\nSending those mails is but the tiny, first step of contributing patches.\nYou know as well as I do that many a times contributors have to work\nthrough many iterations to get their work accepted.\n\nSo while send-email helps with one direction, everything after that is\nhard, manual work.\n\n> > We do not even have a section on Outlook in our SubmittingPatches.\n> \n> \"You can write one? Pretty please?\" would be the canonical answer. ;)\n\nSure. And my answer to that is: I cannot write it. Why? Because I cannot\nget it the heck to work. Because Outlook supports writing mails, i.e.\nmessages from humans for humans. You can change the font, insert a nice\nphoto from your vacations, left-justify, right-justify, center the text.\nYou can do all kinds of nice things that you need to do when talking to\nhumans.\n\nYou can even paste a diff, for a human to read. Humans are very good at\nnot even seeing that there is no space at the beginning of the line.\nHumans are also very good at understanding that those 8 spaces are the\nsame as the tab in the source code.\n\nOutlook can also keep excellent track of who was Cc:ed, of mail threads,\nfiltering mails based on a plethora of criteria, integrating with a\ncalendar, etc.\n\nSo Outlook does really an excellent job.\n\nWhat it does *not* to well is something mail was not designed for.\n\n> Maybe we should invent a patch format that copes with broken whitespace?\n\nOr maybe we do not even have to go that far, but maybe we can teach `git\napply` a mode where it is much smarter about whitespace changes and\nwrapped text in the patch it receives?\n\nThat would probably go a long way further to making the patch submission\nprocess we use more friendly to human beings.\n\nIt still would not make it easy to go from replies containing suggestions\nhow to improve the code to the corresponding file/revision.\n\n> >> Users ought to be able to pick, choose, and replace tools as they\n> >> wish as long as an interchange format remains stable and\n> >> widely-supported.\n> >\n> > Right. Let's talk about the interchange format called mails, for the\n> > data called patches. Is it stable and widely-supported?\n> \n> It is stable as it has been around for years and you can choose whether\n> you use git apply or the patch utility.\n\nYou seem to assume that mail clients have an easy time with this supposed\n\"stable\" format.\n\nThey don't.\n\n> It is widely supported as it is raw text so it can be used across\n> different platforms. However it doesn't cope well with email, as email\n> modifies text sometimes such as mangling white spaces.\n\nI \"mangle\" whitespace all the time when I respond to mails. You will note\nthat I re-wrap quoted text to 76 columns/row.\n\nSo I am as guilty as any mail client of your charge.\n\nSorry.\n\n> > Can users really pick and choose the tools they like most to send patches\n> > to the Git project? Like, the Outlook client? Or the GMail client?\n> \n> Of course, see[1] ;)\n> [1] https://public-inbox.org/git/CA+55aFy2AEe7ew5Px=2Uit6hraGV9zFr=JZ57rSYXWMQ4nMjeg@mail.gmail.com/\n\nYou speak in riddles. That link leads to Linus' mail talking about\ncommitterdates and generation numbers.\n\nIt does not help me, not in the slightest, to send a patch via Outlook or\nthe web interface of GoogleMail without risking to get yelled at for\ncorrupting the patch.\n\nCiao,\nDscho\n"},{"id":"299857","messageId":"02c1c636-b0b4-8730-68a6-18f017ed3410@gmail.com","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608221509010.4924@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-08-22T18:05:40Z","receivedAt":"2016-08-22T18:06:06Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 22.08.2016 o 15:18, Johannes Schindelin pisze:\n\n> So unfortunately this thread has devolved. Which is sad. Because all I\n> wanted is to have a change in Git's submission process that would not\n> exclude *so many* developers. That is really all I care about. Not about\n> tools. Not about open vs proprietary, or standards.\n> \n> I just want developers who are already familiar with Git, and come up with\n> an improvement to Git itself, to be able to contribute it without having\n> to pull out their hair in despair.\n\nWhat is lacking in using submitGit tool for those that have problems\nwith sending patches via email?\n\nSubmitting changes in Git comes in three phases:\n - submit email with patches\n - review and discuss patch\n - apply patches from email\n\nPull request via GitHub / Bitbucket / GitLab is easier than sending\npatches via email (pity that GitHub et al. do not have such submitGit-like\nautomation built-in). But I think email, with threaded view, careful\ntrimming of quoted contents, multi-level quotes is superior to exiting\nweb-based solutions.\n\nRegards,\n-- \nJakub Narębski\n\n"},{"id":"299864","messageId":"20160822192152.tghb5eyi74hrr6e4@sigill.intra.peff.net","threadId":"43864","inReplyTo":"CAGZ79kb9x6RHdFeA8WXpq4NFYr-G+B1R7_8u883LO8zvPyr+CQ@mail.gmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-22T19:21:52Z","receivedAt":"2016-08-22T19:22:01Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 19, 2016 at 09:55:54AM -0700, Stefan Beller wrote:\n\n> It was not my intend to start this discussion again with my initial email.\n> I rather wanted to point out how I make progress in doing my own\n> tooling.\n> \n> I mean if email works well for Junio (both as a maintainer as\n> well as a contributor) and Jeff as a contributor, then I can adapt\n> my workflow to that, because these two have brought in\n> 8300 of 33000 non merge patches. (i.e. they had 25% of the\n> patches over the life time of the project and are with the project\n> longer than others IIUC). So why would I demand they change\n> their style just to accommodate one newcomer like me?\n\nEven though I do really like the mail-based workflow, I think this is a\ndangerous line of reasoning. If the project were just me and Junio,\nworking as efficiently as two people possibly can, then sure, asking us\nto change from what works for us would be silly.\n\nBut it's not. We have to make sure that the project community thrives.\nThat includes catering to some degree to occasional contributors, and\ndoing things to attract new members to the community as old ones drift\naway.\n\nYou'll notice that I hand-waved away \"to some degree\" there. There is\ndefinitely a balance to be found in managing the time of the maintainer\nand the reviewers, versus making things easier for new contributors. As\na reductio ad absurdum, the simplest thing for contributors would be to\nmake a vague bug report and have the maintainer produce a polished\npatch. That obviously does not scale. :)\n\nLikewise, it is not just a matter of time spent, but workflows impact\n_who_ will join[1]. Contributing to git is very friendly to a certain\nniche of Unix die-hards, and that impacts who bothers to do so, and\nconsequently, what contributions we see (both to code and to\ndiscussion). There's value in diversity of opinions[2], and we should be\nwary of becoming an obsolete and out-of-touch mono-culture.\n\nSo I say \"dangerous\" because that is one way that open source projects\ncan die: the number of contributors dwindles, development slows, there\nare no new ideas in the community, etc.\n\nI don't think git would ever die off completely; there are too many\nusers. But there have been projects that seem to ossify for many years,\nand are rejuvenated only when they shake up some elements of the\ncommunity or workflow (e.g., mutt is recently seeing such a resurgence;\nsometimes it even takes the form of a follow-on project, like CVS->SVN,\nwith new people).\n\nI don't think we're at that point with git. But it is something to be\nmindful of. It's not clear to me if mutt-loving luddites like myself are\nthe last of a dying breed, or if there will always be enough of us to\nchurn out contributions to projects like git.\n\n-Peff\n\n[1] I think Dscho feels this much more acutely on Git for Windows than\n we do on the regular git mailing list, because the \"who\" audience\n for GfW is much different than the Unix world.\n\n[2] I also think there's such as a thing as \"too many opinions\" in a\n project. If we started rewriting bits of git in Haskell (just to\n pick on a random pretty-far-from-C language), things would get very\n complex very quickly. So again, it's about finding a balance.\n"},{"id":"299866","messageId":"B21604E7033C458EAC5EA0651CFEA8E9@PhilipOakley","threadId":"43864","inReplyTo":"CACsJy8BG63oaLbw0f7try3OpzdphLC7UGAaJ=vgikEB36Pagqg@mail.gmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-08-22T20:38:07Z","receivedAt":"2016-08-22T20:38:15Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Duy Nguyen\" \n> On Mon, Aug 22, 2016 at 8:06 PM, Johannes Schindelin\n> wrote:\n>> My point stands. We are way more uninviting to contributors than\n>> necessary. And a huge part of the problem is that we require contributors\n>> to send their patches inlined into whitespace-preserving mails.\n>\n> We probably can settle this in the next git survey with a new\n> question: what's stopping you from contributing to git?\n> -- \nOne has to be careful that some of this is preaching to the choir.\n\nThose who have difficulty won't be anywhere near the survey. Those that are \nnear the survey will have enough nouce to contribute to the level they \nmanage.\n\nAlso the argument here has started to be at cross purposes about the issues \nvs the solutions.\n\nI do note that dscho's patches now have the extra footer (below the three \ndashes) e.g.\n\nPublished-As: https://github.com/dscho/git/releases/tag/cat-file-filters-v1\nFetch-It-Via: git fetch https://github.com/dscho/git cat-file-filters-v1\n\nIf say I used that, and sent my patch series via Outlook Express (), \nwith it's white space damage, would those footers help once the content has \nbeen reviewed (rather than white spacing style) in the applying the patch?\n\nEven, Is there a way of accepting email that has HTML embedded by the \nclient, rather than [vger, etc.] simply deleting the email as 'not \nacceptable'. Unless users can get past these sort of (to them) petty and \nawkward restrictions, it's going to continue to be difficult to encourage \nparticipation.\n\n--\n\nPhilip\n\nPS Sudden though about the 'Published-As: Fetch-It-Via: ' stuff. I don't \nthink we have a method of 'Fetch-As-A-Series' so that what is received from \nthe server (e.g. GitHub, as a git command equivalent) is just those \npatches/commits in the series, and the recipient can then see if they apply \ncleanly at the point they want to apply them? This would almost be a 'pack \nfile' that is all commit deltas, that can be given to say 'rebase' (or \n'apply'). It could also be expanded back into an mbox format if required...\n\n\n\n"},{"id":"299876","messageId":"20160822225549.GA25383@starla","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608221509010.4924@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-22T22:55:49Z","receivedAt":"2016-08-22T22:56:12Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> On Fri, 19 Aug 2016, Eric Wong wrote:\n> > Johannes Schindelin wrote:\n> > > On Thu, 18 Aug 2016, Eric Wong wrote:\n> > > > Johannes Schindelin wrote:\n> > > >\n> > > > > Old dogs claim the mail list-approach works for them. Nope.\n> > > > > Doesn't. Else you would not have written all those custom\n> > > > > scripts.\n> > > > \n> > > > git and cogito started as a bunch of custom scripts, too.\n> > > \n> > > The difference is that neither git nor cogito were opinionated. Those\n> > > custom scripts are. They are for one particular workflow, with one\n> > > particular mail client, with a strong bias to a Unix-y environment.\n\n\n\n> > I guess this is a fundamental difference between *nix and Windows\n> > culture.\n> \n> I do not understand how you get from \"I wish to make it fun to contribute\n> to Git\" to \"there is a fundamental difference between *nix and Windows\n> culture\".\n\nSorry, I over-quoted by 3 lines.\n\n\n\n> > > We do not even have a section on Outlook in our SubmittingPatches.\n> > > \n> > > Okay, if not the most popular mail client, then web mail? Nope, nope,\n> > > nope. No piping *at all* to external commands from there.\n> > > \n> > > So you basically slam the door shut on the vast majority of email users.\n> > \n> > Users have a choice to use a more scriptable mail client\n> > (but I guess the OS nudges users towards monolithic tools)\n> \n> You call that choice. Are you serious?\n> \n> > > That is not leaving much choice to the users in my book.\n> > \n> > Users of alpine, gnus, mutt, sylpheed, thunderbird, kmail,\n> > roundcube, squirelmail, etc. can all download the source, hack,\n> > fix and customize things. It's easier with smaller software,\n> > of course: git-send-email does not even require learning\n> > the build process or separate download.\n> \n> Now I am getting upset. This is a BS argument. Sure, I can hack the source\n> of these tools.\n>\n> But why on earth do I *have* to? Why can't we use or create an open\n> contribution process *that works without having to work so hard to be able\n> to contribute*?\n\nThe process we have is already open. It may be *nix-centric,\nand *nix may be picky about it's friends, but it is open:\n\n\tAnybody can still contribute today without any sort of\n\tregistration, credentialism, or terms-of-service(*).\n\nI am looking beyond git.\n\nI hate signing up for websites. For many years, I have used\nDebian as a proxy for other projects with less open contribution\nprocesses:\n\n\tapt-get source ...; ; reportbug ...\n\nOf course, going through Debian maintainers is not always\nreliable or efficient.\n\nI foolishly hoped git-svn would put an end to all the\nregistration-required bug tracker instances so I could just\nsend my changes directly to upstream maintainers without any\nsort of registration. Did not happen :<\n\n> So unfortunately this thread has devolved. Which is sad. Because all I\n> wanted is to have a change in Git's submission process that would not\n> exclude *so many* developers. That is really all I care about. Not about\n> tools. Not about open vs proprietary, or standards.\n> \n> I just want developers who are already familiar with Git, and come up with\n> an improvement to Git itself, to be able to contribute it without having\n> to pull out their hair in despair.\n\nWe want the same thing. I just want to go farther and get\npeople familiar with (federated|decentralized) tools instead of\nproprietary and centralized ones.\n\n\n\n(*) I wish git could get rid of the DCO, even. But at least\n it's far better than the \"papers, please\" policy for some\n GNU projects.\n"},{"id":"300047","messageId":"alpine.DEB.2.20.1608241459360.4924@virtualbox","threadId":"43864","inReplyTo":"B21604E7033C458EAC5EA0651CFEA8E9@PhilipOakley","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-24T13:04:54Z","receivedAt":"2016-08-24T13:05:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Philip,\n\nOn Mon, 22 Aug 2016, Philip Oakley wrote:\n\n> From: \"Duy Nguyen\" \n> > On Mon, Aug 22, 2016 at 8:06 PM, Johannes Schindelin\n> > wrote:\n> > > My point stands. We are way more uninviting to contributors than\n> > > necessary. And a huge part of the problem is that we require contributors\n> > > to send their patches inlined into whitespace-preserving mails.\n> >\n> > We probably can settle this in the next git survey with a new\n> > question: what's stopping you from contributing to git?\n> > -- \n> One has to be careful that some of this is preaching to the choir.\n\nExactly.\n\n> I do note that dscho's patches now have the extra footer (below the three\n> dashes) e.g.\n> \n> Published-As: https://github.com/dscho/git/releases/tag/cat-file-filters-v1\n> Fetch-It-Via: git fetch https://github.com/dscho/git cat-file-filters-v1\n> \n> If say I used that, and sent my patch series via Outlook Express (),\n> with it's white space damage, would those footers help once the content has\n> been reviewed (rather than white spacing style) in the applying the patch?\n\nI considered recommending this as some way to improve the review process.\nThe problem, of course, is that it is very easy to craft an email with an\ninnocuous patch and then push some malicious patch to the linked\nrepository.\n\nNow, with somebody like me who would lose a lot when destroying trust, it\nis highly unlikely. But it is possible that in between the hundreds of\nsincere contributors a bad apple tries to sneak in bad stuff.\n\nTherefore, if we were to support a Git-driven contribution process that\n*also* sends mail, that mail needs to be generated by a trusted source, to\nensure that the content of the mail is identical to the original Git\ncommits.\n\nCiao,\nDscho\n"},{"id":"300055","messageId":"alpine.DEB.2.20.1608241509200.4924@virtualbox","threadId":"43864","inReplyTo":"DM5PR17MB1353EFB1F6FE3B05EFDF86DCD3EB0@DM5PR17MB1353.namprd17.prod.outlook.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-24T15:34:02Z","receivedAt":"2016-08-24T15:41:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Arif,\n\nOn Tue, 23 Aug 2016, Arif Khokar wrote:\n\n> On 08/20/2016 03:57 PM, Jakub Narębski wrote:\n> \n> > But perhaps the problem is current lack of tooling in the opposite\n> > direction, namely getting patches from mailing list and applying them\n> > to GitHub repo, or Bitbucket, or GitLab. Though with working Git, it\n> > is something easier than sending patches via email; it is enough that\n> > email client can save email to a file (or better, whole sub-thread to\n> > file or files).\n> \n> Given that public-inbox provides an NNTP interface, couldn't the ARTICLE\n> NNTP command be used to easily retrieve the messages in a\n> given patch series (at least compared to POP or IMAP). Perhaps\n> git-send-email could be modified to include the message-id value of each\n> patch in the series that it sends to the mailing list and include it in\n> the cover letter.\n\nI am no expert in the NNTP protocol (I abandoned News long ago), but if\nyou go from HTML, you can automate the process without requiring changes\nin format-patch.\n\n> Then a script could be written (i.e., git-download-patch) which could\n> parse the cover letter message (specified using its message-id), and\n> download all the patches in series, which can then be applied using\n> git-am. This would in fact take the email client out of the equation in\n> terms of saving patches.\n\nI recently adapted an old script I had to apply an entire patch series\ngiven the GMane link to its cover letter:\n\nhttps://github.com/git-for-windows/build-extra/blob/master/apply-from-gmane.sh\n\nMaybe you find it in you to adapt that to work with public-inbox.org?\n\nCiao,\nJohannes"},{"id":"300103","messageId":"20160824184938.GB8578@whir","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608241509200.4924@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-24T18:49:38Z","receivedAt":"2016-08-24T18:57:51Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi Arif,\n> \n> On Tue, 23 Aug 2016, Arif Khokar wrote:\n> \n> > On 08/20/2016 03:57 PM, Jakub Narębski wrote:\n> > \n> > > But perhaps the problem is current lack of tooling in the opposite\n> > > direction, namely getting patches from mailing list and applying them\n> > > to GitHub repo, or Bitbucket, or GitLab. Though with working Git, it\n> > > is something easier than sending patches via email; it is enough that\n> > > email client can save email to a file (or better, whole sub-thread to\n> > > file or files).\n> > \n> > Given that public-inbox provides an NNTP interface, couldn't the ARTICLE\n> > NNTP command be used to easily retrieve the messages in a\n> > given patch series (at least compared to POP or IMAP). Perhaps\n> > git-send-email could be modified to include the message-id value of each\n> > patch in the series that it sends to the mailing list and include it in\n> > the cover letter.\n\nI think that makes sense; perhaps an X-Git-Followups: header\nfrom send-email which lists the child Message-IDs the same way\nReferences: does for ancestors. (perhaps there's already a\nstandardized header for listing children)\n\nI thought about allowing a giant MIME message with all the\npatches attached, too but that won't work for a large patch\nseries due to size limits along various SMTP hops.\nCompression might make spam filters unhappy, too.\n\n> I am no expert in the NNTP protocol (I abandoned News long ago), but if\n> you go from HTML, you can automate the process without requiring changes\n> in format-patch.\n> \n> > Then a script could be written (i.e., git-download-patch) which could\n> > parse the cover letter message (specified using its message-id), and\n> > download all the patches in series, which can then be applied using\n> > git-am. This would in fact take the email client out of the equation in\n> > terms of saving patches.\n\n\tw3m -dump -dump_source nntp:///\n\nought to already work for news.gmane.org and news.public-inbox.org\n\nThe Net::NNTP Perl module is a standard part of the Perl distro\nfor many years, now (along with Net::SMTP), so that would not\nbe a roadblock for implementing a custom downloader distributed\nwith git.\n\n> I recently adapted an old script I had to apply an entire patch series\n> given the GMane link to its cover letter:\n> \n> https://github.com/git-for-windows/build-extra/blob/master/apply-from-gmane.sh\n> \n> Maybe you find it in you to adapt that to work with public-inbox.org?\n\nI would be hesitant to depend too much on public-inbox.org until\nmore mirrors appear. Even then, NNTP is a better-established\nprotocol and a fallback to news.gmane still works.\n(public-inbox.org is powered by hamsters running on wheels,\n sometimes I let them rest :)\n"},{"id":"300106","messageId":"20160824191238.taeodwd2hz7q55gv@sigill.intra.peff.net","threadId":"43864","inReplyTo":"20160824184938.GB8578@whir","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-24T19:12:38Z","receivedAt":"2016-08-24T19:12:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 24, 2016 at 06:49:38PM +0000, Eric Wong wrote:\n\n> > > Given that public-inbox provides an NNTP interface, couldn't the ARTICLE\n> > > NNTP command be used to easily retrieve the messages in a\n> > > given patch series (at least compared to POP or IMAP). Perhaps\n> > > git-send-email could be modified to include the message-id value of each\n> > > patch in the series that it sends to the mailing list and include it in\n> > > the cover letter.\n> \n> I think that makes sense; perhaps an X-Git-Followups: header\n> from send-email which lists the child Message-IDs the same way\n> References: does for ancestors. (perhaps there's already a\n> standardized header for listing children)\n\nI think that's harder to adapt to some workflows, since it implies\ngenerating all of the message-ids ahead of time (whereas if you are\nfeeding the messages into an existing MUA, it may generate them on the\nfly as it sends).\n\n> I thought about allowing a giant MIME message with all the\n> patches attached, too but that won't work for a large patch\n> series due to size limits along various SMTP hops.\n> Compression might make spam filters unhappy, too.\n\nThis was a problem faced by binary groups on Usenet, which had to split\nlarge files across many messages.\n\nIt has been a long time since I've dealt with those, but I think the\nstate of the art involved using \"1/20\", \"2/20\", etc in the subjects to\npiece together the original. There may also have been header or body\ncontent that included a unique id, so you always knew which messages\nwere part of a set.\n\nThey also used things like forward error correction to handle dropped\nmessages, but I don't think we need to go that far.\n\nSo parsing the \"PATCH 1/20\" headers sounds hacky, but I think it has\nworked for years in other communities.\n\n-Peff\n"},{"id":"300107","messageId":"20160824191651.GC8578@whir","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608241459360.4924@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-24T19:16:51Z","receivedAt":"2016-08-24T19:18:03Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> On Mon, 22 Aug 2016, Philip Oakley wrote:\n> > I do note that dscho's patches now have the extra footer (below the three\n> > dashes) e.g.\n> > \n> > Published-As: https://github.com/dscho/git/releases/tag/cat-file-filters-v1\n> > Fetch-It-Via: git fetch https://github.com/dscho/git cat-file-filters-v1\n> > \n> > If say I used that, and sent my patch series via Outlook Express (),\n> > with it's white space damage, would those footers help once the content has\n> > been reviewed (rather than white spacing style) in the applying the patch?\n> \n> I considered recommending this as some way to improve the review process.\n> The problem, of course, is that it is very easy to craft an email with an\n> innocuous patch and then push some malicious patch to the linked\n> repository.\n\nPerhaps an automated checker of some sort packaged with git\nwould help.\n(And perhaps combinable with the downloader Arif proposed)\n\n> Now, with somebody like me who would lose a lot when destroying trust, it\n> is highly unlikely. But it is possible that in between the hundreds of\n> sincere contributors a bad apple tries to sneak in bad stuff.\n\nYes, I would never mix reviews + patch applications of emails vs\ngit-fetched data. Having a sender providing both is good; but\nthe recipient needs to pick one or the other to use exclusively\nfor that series.\n\nEither look exclusively at what is fetched and respond to that;\nor look exclusively at emails and ignore data from git fetch.\n\nHowever, ensuring the emails and the contents of the git fetch\ncould be done optionally to ensure there's no tampering or\naccidents for other reviewers.\n\n> Therefore, if we were to support a Git-driven contribution process that\n> *also* sends mail, that mail needs to be generated by a trusted source, to\n> ensure that the content of the mail is identical to the original Git\n> commits.\n\nFor decentralized systems, independent reproducibilility is\nneeded. Rather than trusting one source, I'd rather have some\nsort of downloading + checking tool which checks multiple\nmirrors (git protocols and NNTP). That would allow users to\nindependently verify the veracity of what they got emailed vs\nwhat is fetched.\n"},{"id":"300110","messageId":"20160824192725.GD8578@whir","threadId":"43864","inReplyTo":"20160824191238.taeodwd2hz7q55gv@sigill.intra.peff.net","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-24T19:27:25Z","receivedAt":"2016-08-24T19:40:20Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jeff King wrote:\n> On Wed, Aug 24, 2016 at 06:49:38PM +0000, Eric Wong wrote:\n> > > > Given that public-inbox provides an NNTP interface, couldn't the ARTICLE\n> > > > NNTP command be used to easily retrieve the messages in a\n> > > > given patch series (at least compared to POP or IMAP). Perhaps\n> > > > git-send-email could be modified to include the message-id value of each\n> > > > patch in the series that it sends to the mailing list and include it in\n> > > > the cover letter.\n> > \n> > I think that makes sense; perhaps an X-Git-Followups: header\n> > from send-email which lists the child Message-IDs the same way\n> > References: does for ancestors. (perhaps there's already a\n> > standardized header for listing children)\n> \n> I think that's harder to adapt to some workflows, since it implies\n> generating all of the message-ids ahead of time (whereas if you are\n> feeding the messages into an existing MUA, it may generate them on the\n> fly as it sends).\n\nYeah, it would be limited to git send-email users, only :<\n\n> > I thought about allowing a giant MIME message with all the\n> > patches attached, too but that won't work for a large patch\n> > series due to size limits along various SMTP hops.\n> > Compression might make spam filters unhappy, too.\n> \n> This was a problem faced by binary groups on Usenet, which had to split\n> large files across many messages.\n> \n> It has been a long time since I've dealt with those, but I think the\n> state of the art involved using \"1/20\", \"2/20\", etc in the subjects to\n> piece together the original. There may also have been header or body\n> content that included a unique id, so you always knew which messages\n> were part of a set.\n> \n> They also used things like forward error correction to handle dropped\n> messages, but I don't think we need to go that far.\n> \n> So parsing the \"PATCH 1/20\" headers sounds hacky, but I think it has\n> worked for years in other communities.\n\nnzb (an XML format) seems to be the thing for Usenet binaries,\nnowadays. Maybe it's workable for git, maybe it's overkill or\nnot worth it for the two (non-.onion) NNTP servers we have.\n\nnzb seems widely supported enough (on a Debian jessie system):\n\n$ apt-cache search nzb\nsabnzbdplus - web-based binary newsgrabber with nzb support\nsabnzbdplus-theme-classic - classic interface templates for the SABnzbd+ binary newsgrabber\nsabnzbdplus-theme-iphone - transitional package for migration to sabnzbdplus-theme-mobile\nsabnzbdplus-theme-mobile - mobile interface templates for the SABnzbd+ binary newsgrabber\nsabnzbdplus-theme-plush - plush interface templates for the SABnzbd+ binary newsgrabber\nsabnzbdplus-theme-smpl - smpl interface templates for the SABnzbd+ binary newsgrabber\nlibnzb-dev - An nzb based Usenet binary grabber (development files)\nlibnzb0c2a - An nzb based Usenet binary grabber (runtime library)\nlottanzb - simple and automated Usenet downloader for Newzbin (NZB) files\nnzb - Usenet binary grabber\nnzbget - command-line based binary newsgrabber for nzb files\npython-pynzb - unified API for parsing NZB files from NNTP (Usenet) servers\nspotweb - web interface to search and filter Usenet spots\n"},{"id":"300154","messageId":"alpine.DEB.2.20.1608251457310.4924@virtualbox","threadId":"43864","inReplyTo":"20160822225549.GA25383@starla","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-25T12:58:41Z","receivedAt":"2016-08-25T12:59:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Eric,\n\nOn Mon, 22 Aug 2016, Eric Wong wrote:\n\n> Johannes Schindelin wrote:\n>\n> > I just want developers who are already familiar with Git, and come up with\n> > an improvement to Git itself, to be able to contribute it without having\n> > to pull out their hair in despair.\n> \n> We want the same thing. I just want to go farther and get\n> people familiar with (federated|decentralized) tools instead of\n> proprietary and centralized ones.\n\nWhy require users to get familiar with (federated|decentralized) tools\n*unless* they make things provably more convenient? So far, I only see\nthat this would add to the hurdle, not improve things.\n\nCiao,\nDscho\n"},{"id":"300155","messageId":"alpine.DEB.2.20.1608251500210.4924@virtualbox","threadId":"43864","inReplyTo":"DM5PR17MB1353DB7619E47FCD0011DA82D3ED0@DM5PR17MB1353.namprd17.prod.outlook.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-25T13:01:04Z","receivedAt":"2016-08-25T13:01:41Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Arif,\n\nOn Thu, 25 Aug 2016, Arif Khokar wrote:\n\n> On 08/24/2016 09:04 AM, Johannes Schindelin wrote:\n> >\n> > On Mon, 22 Aug 2016, Philip Oakley wrote:\n> \n> >> I do note that dscho's patches now have the extra footer (below the\n> >> three dashes) e.g.\n> >>\n> >> Published-As: https://github.com/dscho/git/releases/tag/cat-file-filters-v1\n> >> Fetch-It-Via: git fetch https://github.com/dscho/git cat-file-filters-v1\n> \n> \n> \n> > I considered recommending this as some way to improve the review process.\n> > The problem, of course, is that it is very easy to craft an email with an\n> > innocuous patch and then push some malicious patch to the linked\n> > repository.\n> \n> It should be possible to verify the SHA1 of the blob before and after \n> the patch is applied given the values listed near the beginning of the \n> git diff output.\n\nThere is no guarantee that the SHA-1 has not been tampered with.\n\nCiao,\nJohannes\n"},{"id":"300156","messageId":"alpine.DEB.2.20.1608251504030.4924@virtualbox","threadId":"43864","inReplyTo":"20160824191651.GC8578@whir","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-25T13:08:11Z","receivedAt":"2016-08-25T13:08:37Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Eric,\n\nOn Wed, 24 Aug 2016, Eric Wong wrote:\n\n> Johannes Schindelin wrote:\n> \n> > Now, with somebody like me who would lose a lot when destroying trust,\n> > it is highly unlikely. But it is possible that in between the hundreds\n> > of sincere contributors a bad apple tries to sneak in bad stuff.\n> \n> Yes, I would never mix reviews + patch applications of emails vs\n> git-fetched data.\n\nWell, such a categorical statement seems to exclude all convenience I had\nin mind.\n\nMy idea was that, say, a web service running on a trusted server with a\ntrusted code base could send mails that would be trusted to contain\ncorrect SHA-1 information, allowing for a review in the mail, but still\nuse the much, much more convenient Git tools to actually work on the code.\n\nI really hope that not everybody is so categorically against introducing\nmuch needed convenience.\n\nCiao,\nDscho\n"},{"id":"300159","messageId":"alpine.DEB.2.20.1608251508280.4924@virtualbox","threadId":"43864","inReplyTo":"02c1c636-b0b4-8730-68a6-18f017ed3410@gmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-25T13:21:35Z","receivedAt":"2016-08-25T13:39:50Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Kuba,\n\nOn Mon, 22 Aug 2016, Jakub Narębski wrote:\n\n> W dniu 22.08.2016 o 15:18, Johannes Schindelin pisze:\n> \n> > So unfortunately this thread has devolved. Which is sad. Because all I\n> > wanted is to have a change in Git's submission process that would not\n> > exclude *so many* developers. That is really all I care about. Not about\n> > tools. Not about open vs proprietary, or standards.\n> > \n> > I just want developers who are already familiar with Git, and come up with\n> > an improvement to Git itself, to be able to contribute it without having\n> > to pull out their hair in despair.\n> \n> What is lacking in using submitGit tool for those that have problems\n> with sending patches via email?\n\nWhere do I start? And where do I stop? Here is a *very* brief list of\nissues from the top of my head (and the history of my web browser):\n\n- You cannot open a PR on GitHub and include the PR's cover letter as\n cover letter: https://github.com/rtyley/submitgit/issues/9\n\n- You cannot Cc: people explicitly:\n https://github.com/rtyley/submitgit/issues/31\n\n- submitGit does not include any interdiff\n\n- it is really hard to get back from mails to the corresponding commits\n\n- you have to register with yet another service to send mails on your\n behalf. Would be nicer if the mails could be sent from a submitGit\n address (moderated, of course) and did not need a separate registration\n step with some scary permission granting.\n\n- submitGit requires you to go to a separate website to interact with the\n submitGit web app. Would be so much nicer if it were a bot operating on\n PRs.\n\n- comments sent as replies have no connection to the PR *nor* the commits\n they refer to (making submitGit basically a pimped up git-send-email,\n nothing more).\n\n- submitGit would require a substantial effort from me to learn how to\n extend/fix it, to run the web app locally and run its tests. That is a\n rather steep hurdle.\n\nThis is an incomplete list, of course.\n\n> Submitting changes in Git comes in three phases:\n> - submit email with patches\n> - review and discuss patch\n> - apply patches from email\n\nYou forgot a really crucial step. Maybe you did not go through dozens of\niterations in your patch series as I regularly do, or something, so it is\nprobably easy for you to forget:\n\n - find the commit in question, run rebase -i and patch it as suggested\n\nThis is something that costs me quite some time to do. It is easily the\nmost annoying aspect of the mail list-based approach for me.\n\n> Pull request via GitHub / Bitbucket / GitLab is easier than sending\n> patches via email (pity that GitHub et al. do not have such submitGit-like\n> automation built-in). But I think email, with threaded view, careful\n> trimming of quoted contents, multi-level quotes is superior to exiting\n> web-based solutions.\n\nThey are not exiting, but I know what you meant.\n\nThe thing is: GitHub does not need such an automation. Because most\nprojects are pretty happy with the process centered around the web app.\n\nIt is only projects such as Linux, Cygwin and Git itself who refuse to\nallow for tools that would let the majority of potential contributors\nstick with their favorite way to read and write mails (I am talking about\nusers of GMail and Outlook, of course).\n\nCiao,\nDscho"},{"id":"300229","messageId":"alpine.DEB.2.20.1608261007050.4924@virtualbox","threadId":"43864","inReplyTo":"DM5PR17MB13536B19149ABF86ECD07E1AD3ED0@DM5PR17MB1353.namprd17.prod.outlook.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-26T08:08:24Z","receivedAt":"2016-08-26T08:08:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Arif,\n\nOn Thu, 25 Aug 2016, Arif Khokar wrote:\n\n> On 08/25/2016 09:01 AM, Johannes Schindelin wrote:\n> >\n> > On Thu, 25 Aug 2016, Arif Khokar wrote:\n> \n> >>> I considered recommending this as some way to improve the review\n> >>> process. The problem, of course, is that it is very easy to craft\n> >>> an email with an innocuous patch and then push some malicious patch\n> >>> to the linked repository.\n> >>\n> >> It should be possible to verify the SHA1 of the blob before and after\n> >> the patch is applied given the values listed near the beginning of\n> >> the git diff output.\n> >\n> > There is no guarantee that the SHA-1 has not been tampered with.\n> \n> I was implying that the resulting SHA1 of the blob after the malicious\n> patch was applied would differ compared to the resulting blob after\n> applying the innocuous patch. Even if you alter the SHA1 value within\n> the patch itself, it doesn't change the SHA1 of the result (unless\n> you're able to get a hash collision).\n> \n> But, if you want to guarantee that the SHA1 hasn't been tampered in the\n> email, you could sign it with your private GPG key and others could\n> verify the signature with your public key (assuming the web-of-trust\n> applies).\n\nGiven that I try to convince my fellow core Git developers to adopt an\n*easier* patch submission process, that wastes less of contributors' time,\nI would be strongly opposed to requiring a web of trust and GPG signatures\njust to be able to submit patches to git.git.\n\nCiao,\nJohannes\n"},{"id":"300359","messageId":"5e480a5b-3752-55c0-65ed-52ca5802851f@gmail.com","threadId":"43864","inReplyTo":"CACsJy8BG63oaLbw0f7try3OpzdphLC7UGAaJ=vgikEB36Pagqg@mail.gmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-08-27T22:26:33Z","receivedAt":"2016-08-27T22:38:40Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 22.08.2016 o 15:15, Duy Nguyen pisze:\n> On Mon, Aug 22, 2016 at 8:06 PM, Johannes Schindelin\n> wrote:\n>>\n>> My point stands. We are way more uninviting to contributors than\n>> necessary. And a huge part of the problem is that we require contributors\n>> to send their patches inlined into whitespace-preserving mails.\n> \n> We probably can settle this in the next git survey with a new\n> question: what's stopping you from contributing to git?\n\nAdded to second take on proposed questions for Git User's Survey 2016\nhttps://public-inbox.org/git/ae804c55-d145-fc90-e1a9-6ebd6c60453a@gmail.com/T/#u\n'[RFCv2] Proposed questions for \"Git User's Survey 2016\", take two'\n\nMessage-ID: <91a2ffbe-a73b-fbb9-96da-9aea4d439e5a@gmail.com>\n \n-- \nJakub Narębski\n"},{"id":"300360","messageId":"d2c4d54f-e3be-8e17-860c-d9b8bacf68e0@gmail.com","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608251457310.4924@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-08-27T22:38:25Z","receivedAt":"2016-08-27T22:38:43Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 25.08.2016 o 14:58, Johannes Schindelin pisze:\n> On Mon, 22 Aug 2016, Eric Wong wrote:\n>> Johannes Schindelin wrote:\n>>\n>>> I just want developers who are already familiar with Git, and come up with\n>>> an improvement to Git itself, to be able to contribute it without having\n>>> to pull out their hair in despair.\n>>\n>> We want the same thing. I just want to go farther and get\n>> people familiar with (federated|decentralized) tools instead of\n>> proprietary and centralized ones.\n> \n> Why require users to get familiar with (federated|decentralized) tools\n> *unless* they make things provably more convenient? So far, I only see\n> that this would add to the hurdle, not improve things.\n\nArguably for some federated/decentralized tools are preferred\n(for philosophical reasons), even if they do not achieve even feature\nparity with centralized tools (c.f. FSF). Though Git is not there\nto improve the world, just to be better...\n\nOn the other hand some may say that centralized tools (such as GitHub\nand its pull requests) do not achieve feature parity with email based\nworkflow... though the basics are here.\n\nBest regards,\n-- \nJakub Narębski\n\n"},{"id":"300361","messageId":"alpine.DEB.2.20.1608281033340.129229@virtualbox","threadId":"43864","inReplyTo":"d2c4d54f-e3be-8e17-860c-d9b8bacf68e0@gmail.com","subject":"Re: Working with public-inbox.org","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-28T08:36:38Z","receivedAt":"2016-08-28T08:36:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Kuba,\n\nOn Sun, 28 Aug 2016, Jakub Narębski wrote:\n\n> W dniu 25.08.2016 o 14:58, Johannes Schindelin pisze:\n> > On Mon, 22 Aug 2016, Eric Wong wrote:\n> >> Johannes Schindelin wrote:\n> >>\n> >>> I just want developers who are already familiar with Git, and come up with\n> >>> an improvement to Git itself, to be able to contribute it without having\n> >>> to pull out their hair in despair.\n> >>\n> >> We want the same thing. I just want to go farther and get\n> >> people familiar with (federated|decentralized) tools instead of\n> >> proprietary and centralized ones.\n> > \n> > Why require users to get familiar with (federated|decentralized) tools\n> > *unless* they make things provably more convenient? So far, I only see\n> > that this would add to the hurdle, not improve things.\n> \n> Arguably for some federated/decentralized tools are preferred\n> (for philosophical reasons), even if they do not achieve even feature\n> parity with centralized tools (c.f. FSF).\n\nThis statement is false. If you had talked about *your* preference, it\nwould be true. But to state that federated/decentralized tools are\nuniversally preferred is nonsense.\n\nYou know as well as I do that most users/contributors go for convenience.\n\nAnd if you require an inconvenient step (e.g. subscribing to a\nfederated/decentralized philosophy), most potential contributors simply\nstop being potential contributors. End of story.\n\nCiao,\nJohannes"},{"id":"300362","messageId":"alpine.DEB.2.20.1608281036460.129229@virtualbox","threadId":"43864","inReplyTo":"5e480a5b-3752-55c0-65ed-52ca5802851f@gmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-28T08:38:36Z","receivedAt":"2016-08-28T08:38:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Kuba & Duy,\n\nOn Sun, 28 Aug 2016, Jakub Narębski wrote:\n\n> W dniu 22.08.2016 o 15:15, Duy Nguyen pisze:\n> > On Mon, Aug 22, 2016 at 8:06 PM, Johannes Schindelin\n> > wrote:\n> >>\n> >> My point stands. We are way more uninviting to contributors than\n> >> necessary. And a huge part of the problem is that we require contributors\n> >> to send their patches inlined into whitespace-preserving mails.\n> > \n> > We probably can settle this in the next git survey with a new\n> > question: what's stopping you from contributing to git?\n> \n> Added to second take on proposed questions for Git User's Survey 2016\n> https://public-inbox.org/git/ae804c55-d145-fc90-e1a9-6ebd6c60453a@gmail.com/T/#u\n> '[RFCv2] Proposed questions for \"Git User's Survey 2016\", take two'\n> \n> Message-ID: <91a2ffbe-a73b-fbb9-96da-9aea4d439e5a@gmail.com>\n\nI would like to strongly caution against putting too much stock into this\nusers' survey. It is the best we have, granted. Yet I have not heard from\nanybody that they participated in the survey, unless they were also\nsubscribed to the Git mailing list.\n\nCiao,\nJohannes"},{"id":"300367","messageId":"d4c44d3c-7361-2a33-4ae5-03cc45f8a034@gmail.com","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608281033340.129229@virtualbox","subject":"Re: Working with public-inbox.org","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-08-28T11:41:51Z","receivedAt":"2016-08-28T11:42:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Hello Johannes,\n\nW dniu 28.08.2016 o 10:36, Johannes Schindelin pisze:\n> On Sun, 28 Aug 2016, Jakub Narębski wrote:\n>> W dniu 25.08.2016 o 14:58, Johannes Schindelin pisze:\n>>> On Mon, 22 Aug 2016, Eric Wong wrote:\n>>>> Johannes Schindelin wrote:\n>>>>\n>>>>> I just want developers who are already familiar with Git, and come up with\n>>>>> an improvement to Git itself, to be able to contribute it without having\n>>>>> to pull out their hair in despair.\n>>>>\n>>>> We want the same thing. I just want to go farther and get\n>>>> people familiar with (federated|decentralized) tools instead of\n>>>> proprietary and centralized ones.\n>>>\n>>> Why require users to get familiar with (federated|decentralized) tools\n>>> *unless* they make things provably more convenient? So far, I only see\n>>> that this would add to the hurdle, not improve things.\n>>\n>> Arguably for some federated/decentralized tools are preferred\n>> (for philosophical reasons), even if they do not achieve even feature\n>> parity with centralized tools (c.f. FSF).\n\nPhilosophical and ideological reasons.\n\n> This statement is false. If you had talked about *your* preference, it\n> would be true. But to state that federated/decentralized tools are\n> universally preferred is nonsense.\n\nThe key word is \"some\" (or, if you prefer, \"a few\").\n\n> You know as well as I do that most users/contributors go for convenience.\n> \n> And if you require an inconvenient step (e.g. subscribing to a\n> federated/decentralized philosophy), most potential contributors simply\n> stop being potential contributors. End of story.\n\nFor some people registering on GitHub and using web interface (though\nI think there is also command line interface, don't know if it covers\nPRs) would be the inconvenient step. Just saying.\n\n\nWhat I would like to see is bidirectional bridge between email and\nGitHub (and possibly other hosting sites), so that everybody could use\ntheir favorite interface, be it Git + email client, or Git + web browser\n(or desktop client for GitHub). Just like thanks to Gmane and Gmane-like\npublic-inbox I can use either email client or news reader, and it is\n[nearly] transparent regarding to which one I use.\n\nEven better if hosting site implementation (of pull requests, etc.)\nwere based on federated systems (like email, or Usenet, or IRC, or XMPP),\nand not closed in walled gardens; with hosting site just being one\nparticular implementation (like e.g. Ghost blog engine, and Ghost Pro\nhosting site).\n\nI agree that lowering barriers to contribution for new class of users\n(like MS Windows users; setting up MTA on Linux etc. for git-send-email\nor git-imap-send is not very complicated), if it would be possible\nwithout inconveniencing existing reviewers... which are even more\nimportant, judging by the amount of \"needs review\" messages in\n\"What's cooking...\".\n\nBest,\n-- \nJakub Narębski\n\n"},{"id":"300370","messageId":"bb1ee52f-c4b6-ded3-19af-ddb7b65b376d@gmail.com","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608281036460.129229@virtualbox","subject":"Announcing Git User's Survey 2016 [was: Working with public-inbox.org]","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-08-28T13:45:47Z","receivedAt":"2016-08-28T13:46:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Hello Johannes,\n\nW dniu 28.08.2016 o 10:38, Johannes Schindelin pisze:\n> On Sun, 28 Aug 2016, Jakub Narębski wrote:\n>> W dniu 22.08.2016 o 15:15, Duy Nguyen pisze:\n>>> On Mon, Aug 22, 2016 at 8:06 PM, Johannes Schindelin\n>>> wrote:\n>>>>\n>>>> My point stands. We are way more uninviting to contributors than\n>>>> necessary. And a huge part of the problem is that we require contributors\n>>>> to send their patches inlined into whitespace-preserving mails.\n>>>\n>>> We probably can settle this in the next git survey with a new\n>>> question: what's stopping you from contributing to git?\n>>\n>> Added to second take on proposed questions for Git User's Survey 2016\n>> https://public-inbox.org/git/ae804c55-d145-fc90-e1a9-6ebd6c60453a@gmail.com/T/#u\n>> '[RFCv2] Proposed questions for \"Git User's Survey 2016\", take two'\n>>\n>> Message-ID: <91a2ffbe-a73b-fbb9-96da-9aea4d439e5a@gmail.com>\n> \n> I would like to strongly caution against putting too much stock into this\n> users' survey. It is the best we have, granted. Yet I have not heard from\n> anybody that they participated in the survey, unless they were also\n> subscribed to the Git mailing list.\n\nI tried in past and will try for this year Git User's Survey to be\nannounced more widely than just Git mailing list (git@vger.kernel.org).\n\n\nAnd I think it was successful; we had 6385 responses in the survey\nfrom 2012 (the one without analysis on Git Wiki) - the last one,\nthe maximum of responses we had was 11498 responses in 2011.\nThis is almost an order of magnitude more than number of past and\ncurrent contributors (\"git shortlog -s | wc -l\"), and I think\nmuch more than all current readers and watchers of Git mailing list.\n\nIn 2011 there was \"How did you hear about this Git User's Survey?\"\nquestion at the end (with 7022 responses out of 11498); most popular\nanswers were\n - news web site or social news site (e.g. Digg, Reddit) 1592 / 22.7%\n - git hosting site 1315 / 18.7%\n - other - please specify 1287 / 18.3%\n (which was not git mailing list)\n ...\n - git mailing list 230 / 3.3%\t \n - git-related mailing list (msysGit, ...) 53 / 0.8%\nhttps://git.wiki.kernel.org/index.php/GitSurvey2011#35._How_did_you_hear_about_this_Git_User.27s_Survey.3F\n\nIn 2012 I have used different channels for different announcements;\nexamining channel list shows that Git Homepage one was most used.\nThis does not mean that people who selected those answers, or used\nthat channels do not read git mailing list; they might just find\nthe news somewhere else first.\n\nAlso, \"Which communication channel(s) do you use?\" in 2011, there were\nonly 387 responders who selected git@vger.kernel.org out of 11498\nin total (and out of 1018 people who selected at least one answer\nin this question). Though some people might though lurking is not use...\nhttps://git.wiki.kernel.org/index.php/GitSurvey2011#32._Which_communication_channel.28s.29_do_you_use.3F\n\n\n\nI am not saying that there would be no bias in Git User's Survey\n2016 responses. I agree with you that we should take caution\nwhen analyzing results of \"What's stopping you from contributing\nto Git?\" question. But it might be nor as bad as you fear.\n\n\nThat said, where should Git User's Survey 2016 be announced?\nThe ones that should be easy are:\n - Git mailing list, and related lists\n - #git IRC channel, and its description (and other IRC channels)\n - Git page on Google+\n - Git Homepage\n - Git Wiki\n - Git Rev News\n\nThe ones that would be harder are git hosting sites, among others\nthe GitHub blog.\n\nThe ones that would be quite difficult are news sites and news\naggregation sites, such as LWN.net or HackerNews.\n\nWhere else?\n\nThanks in advance,\n-- \nJakub Narębski\n\n"},{"id":"300372","messageId":"60e7feda-5376-e1f2-1797-9e6dedf3c0b0@gmail.com","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608251508280.4924@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-08-28T18:23:58Z","receivedAt":"2016-08-28T18:24:57Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Hello Johannes,\n\nW dniu 25.08.2016 o 15:21, Johannes Schindelin pisze:\n> On Mon, 22 Aug 2016, Jakub Narębski wrote:\n>> W dniu 22.08.2016 o 15:18, Johannes Schindelin pisze:\n>>\n>>> So unfortunately this thread has devolved. Which is sad. Because all I\n>>> wanted is to have a change in Git's submission process that would not\n>>> exclude *so many* developers. That is really all I care about. Not about\n>>> tools. Not about open vs proprietary, or standards.\n>>>\n>>> I just want developers who are already familiar with Git, and come up with\n>>> an improvement to Git itself, to be able to contribute it without having\n>>> to pull out their hair in despair.\n>>\n>> What is lacking in using submitGit tool for those that have problems\n>> with sending patches via email?\n> \n> Where do I start? And where do I stop? Here is a *very* brief list of\n> issues from the top of my head (and the history of my web browser):\n\nLet me reorder those issues and group them into specific categories.\n \n> - You cannot open a PR on GitHub and include the PR's cover letter as\n> cover letter: https://github.com/rtyley/submitgit/issues/9\n> \n> - you have to register with yet another service to send mails on your\n> behalf. Would be nicer if the mails could be sent from a submitGit\n> address (moderated, of course) and did not need a separate registration\n> step with some scary permission granting.\n> \n> - submitGit requires you to go to a separate website to interact with the\n> submitGit web app. Would be so much nicer if it were a bot operating on\n> PRs.\n\nThose are issues about lack of integration (or need for better integration)\nwith GitHub pull requests. I don't know if tighter integration would be\npossible (without going the route of web browser plugin, like ZenHub) with\ncurrent API. Note that many integrations require you to go and use their\nseparate site, like e.g. HuBoard.\n\nAlso, for some people registering on GitHub is \"yet another service\"... ;-)\n\n> - You cannot Cc: people explicitly:\n> https://github.com/rtyley/submitgit/issues/31\n> \n> - submitGit does not include any interdiff\n\nThese are, I think, mainly related to lack of support for series *iteration*,\nfor sending new version of patch series / of pull request.\n\nI don't know how well GitHub pull requests deal with iteration and\nrefinement, and what is available as API to apps such as submitGit.\n\n> \n> - it is really hard to get back from mails to the corresponding commits\n> \n> - comments sent as replies have no connection to the PR *nor* the commits\n> they refer to (making submitGit basically a pimped up git-send-email,\n> nothing more).\n\nI guess that turning submitGit into two-way bridge between email and PR's\nwould be quite difficult, if at all possible. For one, it would have\nto parse emails to turn response as email into comment on diff in PR.\nFor second, I'm not sure if all features of email workflow are possible\nto represent in PR's: cover letter, comments for individual commits,\ncommits about commit messages, commits about changes, free-form comments.\nBut maybe they are possible; the trouble would be in translating back\nand forth.\n\n> - submitGit would require a substantial effort from me to learn how to\n> extend/fix it, to run the web app locally and run its tests. That is a\n> rather steep hurdle.\n\nWell, you cannot extend/fix GitHub at all yourself, isn't it? ;-P\n\n> \n> This is an incomplete list, of course.\n\nRight.\n\n>> Submitting changes in Git comes in three phases:\n>> - submit email with patches\n>> - review and discuss patch\n>> - apply patches from email\n> \n> You forgot a really crucial step. Maybe you did not go through dozens of\n> iterations in your patch series as I regularly do, or something, so it is\n> probably easy for you to forget:\n> \n> - find the commit in question, run rebase -i and patch it as suggested\n> \n> This is something that costs me quite some time to do. It is easily the\n> most annoying aspect of the mail list-based approach for me.\n\nI probably don't have as many topics in flight, and maybe the number of\niterations is smaller, but I don't remember having troubles with that.\n\nWell, when I was most active doung Git development I were using StGit\npatch management interface instead of rebase -i; I think it makes things\neasier. Perhaps git-series could replace it, or augment it.\n\n>> Pull request via GitHub / Bitbucket / GitLab is easier than sending\n>> patches via email (pity that GitHub et al. do not have such submitGit-like\n>> automation built-in). But I think email, with threaded view, careful\n>> trimming of quoted contents, multi-level quotes is superior to exiting\n>> web-based solutions.\n> \n> They are not exiting, but I know what you meant.\n\nThat was a typo: s/exiting/existing/\n \n> The thing is: GitHub does not need such an automation. Because most\n> projects are pretty happy with the process centered around the web app.\n\nIt might be that they don't need features not available in a web app.\nIt might be that it is only way they know. Not all projects are happy\nto being on GitHub even if they are happy with using hosted git.\n\nAnd they were probably created after GitHub / GitLab / Bitbucket were\nhere. Also - citation needed.\n\n> It is only projects such as Linux, Cygwin and Git itself who refuse to\n> allow for tools that would let the majority of potential contributors\n> stick with their favorite way to read and write mails (I am talking about\n> users of GMail and Outlook, of course).\n\nThose are projects that started before GitHub (for obvious reasons), and\nwhich created a good enough workflow based on email. It might be that\nthey are ossified relics, or it might be that they don't want to trade\nadvantages of email based workflow for advantages of web app based workflow.\n\n\nFirst, email clients and Usenet news readers support threading. I haven't\nfound a good web app that supports threading well (though it might be\na matter of small set of such apps examined by me). They allow marking\nand labeling posts to return back later.\n\nSecond, email allows offline work, and handle well sporadic Internet\nconnection. As far as I know web apps do not handle breaks in net\naccess well, but I might be mistaken. Hopefully this problem would\nvanish with improving broadband... though there always would be places\nwithout constant always-on Internet connection.\n\nThird, email (or rather conventions around email) allows to provide\n - description of the whole series (in cover letter)\n - comments for each commit individually (outside of commit message)\n - make commit or series be a reply to discussion (useful with WIPs)\nFor reviewer it allows to\n - comment on the whole series in response to cover letter\n - comment on individual commit\n - comment on the commit message\n - comment on the description of commit\n - comment on changes\n - start a discussion based on a commit\n - propose improvements as patches\n\nAre all of them possible in PR's?\n\n\nTo reiterate what I have said elsewhere in this thread: while it is\na good idea to lower barriers to contribution, especially for new classes\nof users (like MS Windows users, without a way to easily install and\nconfigure MTA so that git-send-email and/or git-imap-send just works,\nor with default email client without support for preserving whitespace\nand monospace fonts), it is reviewers and maintainers that are sparse\nresource.\n\nBest,\n-- \nJakub Narębski\n\n"},{"id":"300405","messageId":"alpine.DEB.2.20.1608290719270.129229@virtualbox","threadId":"43864","inReplyTo":"d4c44d3c-7361-2a33-4ae5-03cc45f8a034@gmail.com","subject":"Re: Working with public-inbox.org","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-29T05:35:17Z","receivedAt":"2016-08-29T05:35:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Kuba,\n\nOn Sun, 28 Aug 2016, Jakub Narębski wrote:\n\n> W dniu 28.08.2016 o 10:36, Johannes Schindelin pisze:\n> > On Sun, 28 Aug 2016, Jakub Narębski wrote:\n> >\n> >> Arguably for some federated/decentralized tools are preferred\n> >> (for philosophical reasons), even if they do not achieve even feature\n> >> parity with centralized tools (c.f. FSF).\n> \n> Philosophical and ideological reasons.\n\nMy mistake. In my mind, I corrected the grammar to skip the \"for\", not to\ninsert \"developers\" after \"some\".\n\nStill. Based on my experience in the workforce, it appears to me that you\nstill confuse ease with convenience: many Windows developers I worked with\nare quite capable of doing much more complicated things than configuring\nimap-send/send-email. But why would they?\n\nComing back to your \"philosophical and ideological reasons\". IMO it is not\nvery wise to go down that path. Much wiser would it be to make provable\ntime savings a guiding principle.\n\nCiao,\nJohannes"},{"id":"300445","messageId":"alpine.DEB.2.20.1608291118500.129229@virtualbox","threadId":"43864","inReplyTo":"60e7feda-5376-e1f2-1797-9e6dedf3c0b0@gmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-29T10:46:52Z","receivedAt":"2016-08-29T10:47:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Kuba,\n\nOn Sun, 28 Aug 2016, Jakub Narębski wrote:\n\n> W dniu 25.08.2016 o 15:21, Johannes Schindelin pisze:\n> > On Mon, 22 Aug 2016, Jakub Narębski wrote:\n> >> W dniu 22.08.2016 o 15:18, Johannes Schindelin pisze:\n> >>\n> >>> So unfortunately this thread has devolved. Which is sad. Because all\n> >>> I wanted is to have a change in Git's submission process that would\n> >>> not exclude *so many* developers. That is really all I care about.\n> >>> Not about tools. Not about open vs proprietary, or standards.\n> >>>\n> >>> I just want developers who are already familiar with Git, and come\n> >>> up with an improvement to Git itself, to be able to contribute it\n> >>> without having to pull out their hair in despair.\n> >>\n> >> What is lacking in using submitGit tool for those that have problems\n> >> with sending patches via email?\n> > \n> > Where do I start? And where do I stop? Here is a *very* brief list of\n> > issues from the top of my head (and the history of my web browser):\n> \n> Let me reorder those issues and group them into specific categories.\n\nI am afraid that this is not the direction I was interested in.\n\nYou asked how submitGit fell short of my goal to provide a more convenient\nand more efficient submission process, and I listed a couple of reasons.\n\nI am really more interested in a better process, than in a point-by-point\ndiscussion of the reasons I listed.\n\nAnd some of those discussions really only distract. This comment, for\nexample, seems to be designed to veer off in a direction that, quite\nfrankly, does not matter for what I *really* wanted to discuss:\n\n> > - submitGit requires you to go to a separate website to interact with the\n> > submitGit web app. Would be so much nicer if it were a bot operating on\n> > PRs.\n> \n> [...]\n> \n> Also, for some people registering on GitHub is \"yet another service\"... ;-)\n\nI am really curious how this is supposed to keep the discussion rational.\n\n*Of course* I implied that it is bad enough to require contributors to\nregister with one web service, and that requiring to register with *yet\nanother service* is just excessive.\n\nSheesh.\n\n> > - You cannot Cc: people explicitly:\n> > https://github.com/rtyley/submitgit/issues/31\n> > \n> > - submitGit does not include any interdiff\n> \n> These are, I think, mainly related to lack of support for series *iteration*,\n> for sending new version of patch series / of pull request.\n\nYes, of course. Because that is what makes the process so particularly\ntedious, thankyouverymuch.\n\n> I don't know how well GitHub pull requests deal with iteration and\n> refinement, and what is available as API to apps such as submitGit.\n\nHmm. Then it may be a good idea if I let you find out before we continue\nto discuss these bullet points that I never wanted to discuss.\n\n> > - submitGit would require a substantial effort from me to learn how to\n> > extend/fix it, to run the web app locally and run its tests. That is a\n> > rather steep hurdle.\n> \n> Well, you cannot extend/fix GitHub at all yourself, isn't it? ;-P\n\nSure you can. There is an API and you can register hooks. You can do even\nmore advanced stuff [*1*].\n\n> >> Submitting changes in Git comes in three phases:\n> >> - submit email with patches\n> >> - review and discuss patch\n> >> - apply patches from email\n> > \n> > You forgot a really crucial step. Maybe you did not go through dozens of\n> > iterations in your patch series as I regularly do, or something, so it is\n> > probably easy for you to forget:\n> > \n> > - find the commit in question, run rebase -i and patch it as suggested\n> > \n> > This is something that costs me quite some time to do. It is easily the\n> > most annoying aspect of the mail list-based approach for me.\n> \n> I probably don't have as many topics in flight, and maybe the number of\n> iterations is smaller, but I don't remember having troubles with that.\n\nWell, aren't you lucky.\n\nI bet you did not intend to sound condescending there, even.\n\n> > It is only projects such as Linux, Cygwin and Git itself who refuse to\n> > allow for tools that would let the majority of potential contributors\n> > stick with their favorite way to read and write mails (I am talking\n> > about users of GMail and Outlook, of course).\n> \n> Those are projects that started before GitHub (for obvious reasons), and\n> which created a good enough workflow based on email. It might be that\n> they are ossified relics, or it might be that they don't want to trade\n> advantages of email based workflow for advantages of web app based\n> workflow.\n\nThose are projects that started before Git was invented. Yet all three\nprojects traded the advantages of patches and tarballs for advantages of\nusing Git.\n\n> First, email clients and Usenet news readers support threading. I\n> haven't found a good web app that supports threading well (though it\n> might be a matter of small set of such apps examined by me). They allow\n> marking and labeling posts to return back later.\n> \n> Second, email allows offline work, and handle well sporadic Internet\n> connection. As far as I know web apps do not handle breaks in net\n> access well, but I might be mistaken. Hopefully this problem would\n> vanish with improving broadband... though there always would be places\n> without constant always-on Internet connection.\n> \n> Third, email (or rather conventions around email) allows to provide\n> - description of the whole series (in cover letter)\n> - comments for each commit individually (outside of commit message)\n> - make commit or series be a reply to discussion (useful with WIPs)\n> For reviewer it allows to\n> - comment on the whole series in response to cover letter\n> - comment on individual commit\n> - comment on the commit message\n> - comment on the description of commit\n> - comment on changes\n> - start a discussion based on a commit\n> - propose improvements as patches\n\nI find these reasons to be more a defense of \"ossified practices\" than\nbased in practical considerations.\n\nFor example, it is delusional to think that you can do any proper review\nof any moderately complex patch without having access to a worktree\nreflecting the revision after the patch.\n\nSo this entire idea that review is inherently something you would want to\nbe able to do without having access to a Git repository reflecting the\npatches in question is an idea I reject flat out.\n\nFor the record, I have used GitHub Pull Requests *extensively*, as\ncontributor, as reviewer and as maintainer.\n\nThe Pull Request web interface has changed over time, but one thing\nremained constant: it was always much more efficient to interact with than\ngoing through the mail list.\n\nThe commit diff is naturally linked to *the commit*.\n\nIf I reply to notification emails when somebody left a comment, it is\nautomatically turned into a reply on the web.\n\nIf I do not want to reply via email, or if I need to see a bigger context,\nthe notification email has a link which opens the web interface, where I\ncan easily not only increase the diff context but also see other files in\nthe same revision, e.g. to check a signature in a .h file.\n\nThese are just a few things that are essential to efficient code review,\nand that are simply impossible with a mailing list approach, unless it is\nopinionated by requiring specific tooling to deal with the fact that code\nis transported through a code-hostile medium.\n\nSo please understand that I am really interested in more efficient code\nreview instead of a lengthy philosophical discussions, and that I am\nreally saddened that I could not gain anything from your mail in that\nrespect.\n\nI really hope that something constructive comes out of this whole\ndiscussion, because if we simply stick with this unwieldy patch submission\nprocess that costs so much of my time, then I really only lost time for\nnothing in return.\n\nCiao,\nJohannes\n\nFootnote *1*: I wrote a little GreaseMonkey script to add a TOC button to\nthe GitHub wiki editor: https://tomancaklab.github.io/gfm-add-toc.user.js\nSimilar extensions can be implemented to augment the PR workflow to your\nliking, with the advantage of being opt-in."},{"id":"301489","messageId":"alpine.DEB.2.20.1609091503410.129229@virtualbox","threadId":"43864","inReplyTo":"bb1ee52f-c4b6-ded3-19af-ddb7b65b376d@gmail.com","subject":"Re: Announcing Git User's Survey 2016 [was: Working with public-inbox.org]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-09-09T13:06:48Z","receivedAt":"2016-09-09T13:07:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Kuba,\n\nOn Sun, 28 Aug 2016, Jakub Narębski wrote:\n\n> W dniu 28.08.2016 o 10:38, Johannes Schindelin pisze:\n>\n> > I would like to strongly caution against putting too much stock into\n> > this users' survey. It is the best we have, granted. Yet I have not\n> > heard from anybody that they participated in the survey, unless they\n> > were also subscribed to the Git mailing list.\n> \n> I tried in past and will try for this year Git User's Survey to be\n> announced more widely than just Git mailing list (git@vger.kernel.org).\n\nI did not mean to criticise you. I think you are doing the best you can,\nand it is valuable.\n\nMy point is: many professional developers use Git not necessarily because\nthey want to, but because their day job requires them to do so.\n\nI *highly* doubt that we reach a notable fraction of those developers,\neven if they are arguably power users of any development tool, including\nGit.\n\nThe question is not so much how to advertise the survey. I skip almost all\nsurveys I am asked to participate in, because I am just a little bit busy\nall the time. I feel that my colleagues do the same. Unless forced to take\na survey, they skip it.\n\nCiao,\nDscho"},{"id":"301540","messageId":"feae2490-8d53-ed3a-d9a5-cc8907bc91d6@gmail.com","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1609091503410.129229@virtualbox","subject":"Re: Announcing Git User's Survey 2016 [was: Working with public-inbox.org]","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-09-09T18:51:23Z","receivedAt":"2016-09-09T18:51:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Hello Johannes,\n\nW dniu 09.09.2016 o 15:06, Johannes Schindelin napisał:\n> On Sun, 28 Aug 2016, Jakub Narębski wrote:\n>> W dniu 28.08.2016 o 10:38, Johannes Schindelin pisze:\n>>\n>>> I would like to strongly caution against putting too much stock into\n>>> this users' survey. It is the best we have, granted. Yet I have not\n>>> heard from anybody that they participated in the survey, unless they\n>>> were also subscribed to the Git mailing list.\n>>\n>> I tried in past and will try for this year Git User's Survey to be\n>> announced more widely than just Git mailing list (git@vger.kernel.org).\n> \n> I did not mean to criticise you. I think you are doing the best you can,\n> and it is valuable.\n[...]\n> \n> The question is not so much how to advertise the survey. I skip almost all\n> surveys I am asked to participate in, because I am just a little bit busy\n> all the time. I feel that my colleagues do the same. Unless forced to take\n> a survey, they skip it.\n\nRight, that's a problem. Thanks for reminding me.\n\nI hope that the fact that by default (via the use of cookies) you can\nreturn to Survs.com survey at later time (assuming that you do it from the\nsame computer and the same web browser), and continue responding. Taking\n30 minutes or more at once may be a problem, taking 10 x 3 minutes may\nnot be.\n\nBut I won't have too much hope...\n-- \nJakub Narębski\n"},{"id":"311276","messageId":"alpine.DEB.2.20.1702101707060.3496@virtualbox","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1608241509200.4924@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-02-10T16:10:12Z","receivedAt":"2017-02-10T16:12:30Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Arif,\n\nOn Wed, 24 Aug 2016, Johannes Schindelin wrote:\n\n> On Tue, 23 Aug 2016, Arif Khokar wrote:\n> \n> > On 08/20/2016 03:57 PM, Jakub Narębski wrote:\n> > \n> > > But perhaps the problem is current lack of tooling in the opposite\n> > > direction, namely getting patches from mailing list and applying\n> > > them to GitHub repo, or Bitbucket, or GitLab. Though with working\n> > > Git, it is something easier than sending patches via email; it is\n> > > enough that email client can save email to a file (or better, whole\n> > > sub-thread to file or files).\n> > \n> > Given that public-inbox provides an NNTP interface, couldn't the\n> > ARTICLE NNTP command be used to easily retrieve the\n> > messages in a given patch series (at least compared to POP or IMAP).\n> > Perhaps git-send-email could be modified to include the message-id\n> > value of each patch in the series that it sends to the mailing list\n> > and include it in the cover letter.\n> \n> I am no expert in the NNTP protocol (I abandoned News long ago), but if\n> you go from HTML, you can automate the process without requiring changes\n> in format-patch.\n> \n> > Then a script could be written (i.e., git-download-patch) which could\n> > parse the cover letter message (specified using its message-id), and\n> > download all the patches in series, which can then be applied using\n> > git-am. This would in fact take the email client out of the equation\n> > in terms of saving patches.\n> \n> I recently adapted an old script I had to apply an entire patch series\n> given the GMane link to its cover letter:\n> \n> https://github.com/git-for-windows/build-extra/blob/master/apply-from-gmane.sh\n> \n> Maybe you find it in you to adapt that to work with public-inbox.org?\n\nOh well. That would have been too easy a task, right?\n\nAs it happens, I needed this functionality myself (when reworking my\ngit-path-in-subdir patch to include Mike Rappazzo's previous patch series\nthat tried to fix the same bug).\n\nI copy-edited the script to work with public-inbox.org, it accepts a\nMessage-ID or URL or GMane URL and will try to apply the patch (or patch\nseries) on top of the current revision:\n\nhttps://github.com/git-for-windows/build-extra/blob/2268850552c7/apply-from-public-inbox.sh\n\nCiao,\nJohannes"},{"id":"311390","messageId":"d16546a4-25be-7b85-3191-e9393fda1164@hotmail.com","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1702101707060.3496@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Arif Khokar","fromEmail":"arif.i.khokar@gmail.com","sentAt":"2017-02-13T05:52:32Z","receivedAt":"2017-02-13T05:52:41Z","isPatch":true,"sender":{"key":"arif.i.khokar@gmail.com","avatar":null},"body":"On 02/10/2017 11:10 AM, Johannes Schindelin wrote:\n> Hi Arif,\n>\n> On Wed, 24 Aug 2016, Johannes Schindelin wrote:\n\n>> I recently adapted an old script I had to apply an entire patch series\n>> given the GMane link to its cover letter:\n>>\n>> https://github.com/git-for-windows/build-extra/blob/master/apply-from-gmane.sh\n>>\n>> Maybe you find it in you to adapt that to work with public-inbox.org?\n>\n> Oh well. That would have been too easy a task, right?\n>\n> As it happens, I needed this functionality myself (when reworking my\n> git-path-in-subdir patch to include Mike Rappazzo's previous patch series\n> that tried to fix the same bug).\n>\n> I copy-edited the script to work with public-inbox.org, it accepts a\n> Message-ID or URL or GMane URL and will try to apply the patch (or patch\n> series) on top of the current revision:\n>\n> https://github.com/git-for-windows/build-extra/blob/2268850552c7/apply-from-public-inbox.sh\n\nThanks for the link. One thing that comes to mind that is that it may \nbe better to just download the patches and then manually apply them \nafterwords rather than doing it in the script itself. Or at least add \nan option to the script to not automatically invoke git am.\n\nGetting back to the point I made when this thread was still active, I \nstill think it would be better to be able to list the message-id values \nin the header or body of the cover letter message of a patch series \n(preferably the former) in order to facilitate downloading the patches \nvia NNTP from gmane or public-inbox.org. That would make it easier \ncompared to the different, ad-hoc, methods that exist for each email client.\n\nAlternatively, or perhaps in addition to the list of message-ids, a list \nof URLs to public-inbox.org or gmane messages could also be provided for \nthose who prefer to download patches via HTTP.\n"},{"id":"311395","messageId":"alpine.DEB.2.20.1702131533400.3496@virtualbox","threadId":"43864","inReplyTo":"d16546a4-25be-7b85-3191-e9393fda1164@hotmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-02-13T14:37:34Z","receivedAt":"2017-02-13T14:37:56Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Arif,\n\nOn Mon, 13 Feb 2017, Arif Khokar wrote:\n\n> On 02/10/2017 11:10 AM, Johannes Schindelin wrote:\n> >\n> > On Wed, 24 Aug 2016, Johannes Schindelin wrote:\n> \n> > > I recently adapted an old script I had to apply an entire patch\n> > > series given the GMane link to its cover letter:\n> > >\n> > > https://github.com/git-for-windows/build-extra/blob/master/apply-from-gmane.sh\n> > >\n> > > Maybe you find it in you to adapt that to work with\n> > > public-inbox.org?\n> >\n> > Oh well. That would have been too easy a task, right?\n> >\n> > As it happens, I needed this functionality myself (when reworking my\n> > git-path-in-subdir patch to include Mike Rappazzo's previous patch\n> > series that tried to fix the same bug).\n> >\n> > I copy-edited the script to work with public-inbox.org, it accepts a\n> > Message-ID or URL or GMane URL and will try to apply the patch (or\n> > patch series) on top of the current revision:\n> >\n> > https://github.com/git-for-windows/build-extra/blob/2268850552c7/apply-from-public-inbox.sh\n> \n> Thanks for the link. One thing that comes to mind that is that it may\n> be better to just download the patches and then manually apply them\n> afterwords rather than doing it in the script itself. Or at least add\n> an option to the script to not automatically invoke git am.\n\nI actually had expected *you* to put in a little bit of an effort, too. In\nfact, I was very disappointed that you did not even look into porting that\nscript to use public-inbox instead of GMane.\n\n> Getting back to the point I made when this thread was still active, I\n> still think it would be better to be able to list the message-id values\n> in the header or body of the cover letter message of a patch series\n> (preferably the former) in order to facilitate downloading the patches\n> via NNTP from gmane or public-inbox.org. That would make it easier\n> compared to the different, ad-hoc, methods that exist for each email\n> client.\n\nYou can always do that yourself: you can modify your cover letter to\ninclude that information.\n\nNote that doing this automatically in format-patch may not be appropriate,\nas 1) the Message-ID could be modified depending on the mail client used\nto send the mails, and 2) it is not unheard of that a developer\nfinds a bug in the middle of sending a patch series, fixes that bug, and\nregenerates the remainder of the patch series, completely rewriting those\nMessage-IDs.\n\n> Alternatively, or perhaps in addition to the list of message-ids, a list\n> of URLs to public-inbox.org or gmane messages could also be provided for\n> those who prefer to download patches via HTTP.\n\nAt this point, I am a little disinterested in a discussion without code. I\nbrought some code to the table, after all.\n\nCiao,\nJohannes\n"},{"id":"311420","messageId":"xmqqefz1ew1h.fsf@gitster.mtv.corp.google.com","threadId":"43864","inReplyTo":"d16546a4-25be-7b85-3191-e9393fda1164@hotmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-13T19:21:46Z","receivedAt":"2017-02-13T19:21:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Arif Khokar writes:\n\n> ... I\n> still think it would be better to be able to list the message-id\n> values in the header or body of the cover letter message of a patch\n> series (preferably the former) in order to facilitate downloading the\n> patches via NNTP from gmane or public-inbox.org.\n\nYou are looking at builtin/log.c::make_cover_letter()? Patches\nwelcome, but I think you'd need a bit of preparatory refactoring\nto allow gen_message_id() be called for all messages _before_ this\nfunction is called, as currently we generate them as we emit each\npatch.\n\n> Alternatively, or perhaps in addition to the list of message-ids, a\n> list of URLs to public-inbox.org or gmane messages could also be\n> provided for those who prefer to download patches via HTTP.\n\nMany people around here do not want to repeat the mistake of relying\ntoo much on one provider. Listing Message-IDs may be a good idea,\nlisting URLs that are tied to one provider is less so.\n\n"},{"id":"311504","messageId":"acac96da-2404-4f7e-a83d-7648ca448d31@hotmail.com","threadId":"43864","inReplyTo":"xmqqefz1ew1h.fsf@gitster.mtv.corp.google.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Arif Khokar","fromEmail":"arif.i.khokar@gmail.com","sentAt":"2017-02-14T03:55:49Z","receivedAt":"2017-02-14T03:55:59Z","isPatch":true,"sender":{"key":"arif.i.khokar@gmail.com","avatar":null},"body":"On 02/13/2017 02:21 PM, Junio C Hamano wrote:\n> Arif Khokar writes:\n>\n>> ... I\n>> still think it would be better to be able to list the message-id\n>> values in the header or body of the cover letter message of a patch\n>> series (preferably the former) in order to facilitate downloading the\n>> patches via NNTP from gmane or public-inbox.org.\n>\n> You are looking at builtin/log.c::make_cover_letter()? Patches\n> welcome, but I think you'd need a bit of preparatory refactoring\n> to allow gen_message_id() be called for all messages _before_ this\n> function is called, as currently we generate them as we emit each\n> patch.\n\nThank you for the advice; I'll look into it.\n\nOne concern I have regarding this idea is whether or not SMTP servers \ntypically replace a Message-Id header set by the client. If that's the \ncase, then this approach may unexpectedly fail for some people depending \non what email provider they use (if they don't maintain their own MTA \nsetup).\n\n>> Alternatively, or perhaps in addition to the list of message-ids, a\n>> list of URLs to public-inbox.org or gmane messages could also be\n>> provided for those who prefer to download patches via HTTP.\n>\n> Many people around here do not want to repeat the mistake of relying\n> too much on one provider. Listing Message-IDs may be a good idea,\n> listing URLs that are tied to one provider is less so.\n\nI agree. I've actually thought that it would be useful to mirror a \nread-only copy of the mailing list on a public newsgroup that could be \naccessed through a free provider such as eternal-september.org or the \nGoogle groups interface. It certainly would reduce the potential losing \neasy access to the archives of this email list if gmane and \npublic-inbox.org fail. But I suspect doing something like that would \npotentially increase the spam volume substantially for regular \nparticipants/contributors.\n"},{"id":"311505","messageId":"7dbe0866-4a9b-7afe-8f51-ca1d5524d4a4@hotmail.com","threadId":"43864","inReplyTo":"alpine.DEB.2.20.1702131533400.3496@virtualbox","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Arif Khokar","fromEmail":"arif.i.khokar@gmail.com","sentAt":"2017-02-14T03:56:39Z","receivedAt":"2017-02-14T03:56:47Z","isPatch":true,"sender":{"key":"arif.i.khokar@gmail.com","avatar":null},"body":"On 02/13/2017 09:37 AM, Johannes Schindelin wrote:\n> Hi Arif,\n>\n> On Mon, 13 Feb 2017, Arif Khokar wrote:\n\n>> Thanks for the link. One thing that comes to mind that is that it may\n>> be better to just download the patches and then manually apply them\n>> afterwords rather than doing it in the script itself. Or at least add\n>> an option to the script to not automatically invoke git am.\n>\n> I actually had expected *you* to put in a little bit of an effort, too. In\n> fact, I was very disappointed that you did not even look into porting that\n> script to use public-inbox instead of GMane.\n\nI wasn't aware of that expectation. My idea was to use NNTP as a way to \nfacilitate the development of a new git utility that would serve as the \ninverse of git-send-email (sort of like the relationship between git \nformat-patch and git am), rather than using a\n\nIIRC, I had posted some proof-of-concept Perl code to do so back in \nAugust in \n\n\nLooking at public-inbox now at the archives of this group, it appears \nthat several of the messages I sent weren't archived for some reason \n(and I didn't see any more responses to what I posted at the time). The \nmessages are accessible via NNTP when connecting to gmane though.\n\nAlso, looking at the source of the message I referenced, it appears that \nmy MUA decided to base64 encode the message for some reason (which may \nhave resulted in it getting filtered by those who I sent the message to).\n\nI will look into this more now (given yours and Junio's responses).\n\n>> Getting back to the point I made when this thread was still active, I\n>> still think it would be better to be able to list the message-id values\n>> in the header or body of the cover letter message of a patch series\n>> (preferably the former) in order to facilitate downloading the patches\n>> via NNTP from gmane or public-inbox.org. That would make it easier\n>> compared to the different, ad-hoc, methods that exist for each email\n>> client.\n>\n> You can always do that yourself: you can modify your cover letter to\n> include that information.\n\nCertainly, but it would be nice to be able to have it done automatically \nby git format-patch (which I'll look into).\n\n> Note that doing this automatically in format-patch may not be appropriate,\n> as 1) the Message-ID could be modified depending on the mail client used\n> to send the mails\n\nI think the best approach would be not to make including the message-id \nvalues the default behavior. Specifying a new command-line option to \nenable that behavior should address those concerns I think.\n\n> and 2) it is not unheard of that a developer\n> finds a bug in the middle of sending a patch series, fixes that bug, and\n> regenerates the remainder of the patch series, completely rewriting those\n> Message-IDs.\n\nPerhaps, but should something like that not warrant a re-roll of sorts. \nThat is, one should reply to the partial patch series stating that there \nis a bug that renders this particular patch (series) un-usable and the \nre-roll could be posted as a reply to the original cover letter?\n\n>> Alternatively, or perhaps in addition to the list of message-ids, a list\n>> of URLs to public-inbox.org or gmane messages could also be provided for\n>> those who prefer to download patches via HTTP.\n>\n> At this point, I am a little disinterested in a discussion without code. I\n> brought some code to the table, after all.\n\nIf you have the time, please take a look at the message-id I referenced. \n If you need, I can re-post the proof-of-concept code.\n"},{"id":"311506","messageId":"003e1ed8-3770-8790-7ed9-2fc5766711d5@hotmail.com","threadId":"43864","inReplyTo":"7dbe0866-4a9b-7afe-8f51-ca1d5524d4a4@hotmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Arif Khokar","fromEmail":"arif.i.khokar@gmail.com","sentAt":"2017-02-14T03:59:55Z","receivedAt":"2017-02-14T04:00:02Z","isPatch":true,"sender":{"key":"arif.i.khokar@gmail.com","avatar":null},"body":"On 02/13/2017 10:56 PM, Arif Khokar wrote:\n\n> I wasn't aware of that expectation. My idea was to use NNTP as a way to\n> facilitate the development of a new git utility that would serve as the\n> inverse of git-send-email (sort of like the relationship between git\n> format-patch and git am), rather than using a\n\n...custom script that's tightly coupled to gmane and public-inbox.org\n\n"},{"id":"311508","messageId":"xmqqlgt99yeo.fsf@gitster.mtv.corp.google.com","threadId":"43864","inReplyTo":"acac96da-2404-4f7e-a83d-7648ca448d31@hotmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-14T04:41:51Z","receivedAt":"2017-02-14T04:41:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Arif Khokar writes:\n\n> One concern I have regarding this idea is whether or not SMTP servers\n> typically replace a Message-Id header set by the client.\n\nThe clients are supposed to give Message-IDs, but because some\nclients fail to do so, SMTP server implementations are allowed to\nadd an ID to avoid leaving a message nameless (IIRC, 6.3 in\nRFC2821). So \"replace\" would be in violation.\n\nBut some parts of the world ignore RFCs, so...\n\n\n"},{"id":"311509","messageId":"5d7e750d-0586-15c3-43ce-4dc4452a73fa@hotmail.com","threadId":"43864","inReplyTo":"xmqqlgt99yeo.fsf@gitster.mtv.corp.google.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Arif Khokar","fromEmail":"arif.i.khokar@gmail.com","sentAt":"2017-02-14T05:09:50Z","receivedAt":"2017-02-14T05:09:57Z","isPatch":true,"sender":{"key":"arif.i.khokar@gmail.com","avatar":null},"body":"On 02/13/2017 11:41 PM, Junio C Hamano wrote:\n> Arif Khokar writes:\n>\n>> One concern I have regarding this idea is whether or not SMTP servers\n>> typically replace a Message-Id header set by the client.\n>\n> The clients are supposed to give Message-IDs, but because some\n> clients fail to do so, SMTP server implementations are allowed to\n> add an ID to avoid leaving a message nameless (IIRC, 6.3 in\n> RFC2821). So \"replace\" would be in violation.\n>\n> But some parts of the world ignore RFCs, so...\n\nBased on my testing, gmail and comcast (and my work email) will preserve \nthe Message-Id header set by the client, but \nhotmail.com/live.com/outlook.com will replace it with their generated value.\n\nBased on a small sample of email addresses of those who post to this \nlist, it appears that most people are using their own MTA to send email, \nor are using gmail, so they probably wouldn't be affected by the issue.\n"},{"id":"311510","messageId":"20170214051403.jwqpxfyyi5mviah2@sigill.intra.peff.net","threadId":"43864","inReplyTo":"xmqqlgt99yeo.fsf@gitster.mtv.corp.google.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-14T05:14:03Z","receivedAt":"2017-02-14T05:14:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 13, 2017 at 08:41:51PM -0800, Junio C Hamano wrote:\n\n> Arif Khokar writes:\n> \n> > One concern I have regarding this idea is whether or not SMTP servers\n> > typically replace a Message-Id header set by the client.\n> \n> The clients are supposed to give Message-IDs, but because some\n> clients fail to do so, SMTP server implementations are allowed to\n> add an ID to avoid leaving a message nameless (IIRC, 6.3 in\n> RFC2821). So \"replace\" would be in violation.\n> \n> But some parts of the world ignore RFCs, so...\n\nI know there are some terrible servers out there, but I think we can\ndiscount any such server as horribly broken. Rewriting message-ids would\ncause threading problems any time the sender referred to their own\nmessages. So \"format-patch --thread\" would fail to work, and even\nreplying to your own message from your \"sent\" folder would fail.\n\n-Peff\n"},{"id":"311523","messageId":"20170214071324.GA747@starla","threadId":"43864","inReplyTo":"7dbe0866-4a9b-7afe-8f51-ca1d5524d4a4@hotmail.com","subject":"Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2017-02-14T07:13:24Z","receivedAt":"2017-02-14T07:13:32Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Arif Khokar wrote:\n> On 02/13/2017 09:37 AM, Johannes Schindelin wrote:\n> >I actually had expected *you* to put in a little bit of an effort, too. In\n> >fact, I was very disappointed that you did not even look into porting that\n> >script to use public-inbox instead of GMane.\n> \n> I wasn't aware of that expectation. My idea was to use NNTP as a way to\n> facilitate the development of a new git utility that would serve as the\n> inverse of git-send-email (sort of like the relationship between git\n> format-patch and git am), rather than using a\n\nSpeaking for myself, I usually don't expect much, especially\nfrom newcomers. So I am disappointed to see Dscho's disappointment\naimed at you, Arif. Especially since you're not a regular and\nwe have no idea how much free time, attention span, or familiarity\nwith Bourne shell you have.\n\n> IIRC, I had posted some proof-of-concept Perl code to do so back in August\n> in \n> \n> Looking at public-inbox now at the archives of this group, it appears that\n> several of the messages I sent weren't archived for some reason (and I\n> didn't see any more responses to what I posted at the time). The messages\n> are accessible via NNTP when connecting to gmane though.\n\nIt looks like it went to gmane via the meta@public-inbox.org to\ngmane.mail.public-inbox.general mirror, not via the git@vger mirror.\nI can't find it on git@vger's mail-archive.com mirror, either:\n\nhttps://mail-archive.com/search?q=Arif+Khokar&l=git%40vger.kernel.org\n\n> Also, looking at the source of the message I referenced, it appears that my\n> MUA decided to base64 encode the message for some reason (which may have\n> resulted in it getting filtered by those who I sent the message to).\n\nIt probably wasn't base64, but maybe it was one of these:\nhttp://vger.kernel.org/majordomo-taboos.txt\n\nOr it was the SPF softfail which you can see in the headers on both\ngmane and public-inbox.\nIt might even be the '_' (underscore) in your other address.\nBut even Junio gets dropped by vger sometimes:\nhttps://public-inbox.org/git/20170127035753.GA2604@dcvr/\n\nBut if I had to guess, vger gets hit by truckloads of spam and\nthe the backscatter volume could become unimaginable, so perhaps\nit has good reason to discard silently.\n\n\n\nAnyways, the eventual goal of public-inbox is to flip the\nmailing list model backwards into \"archives first\" mode,\nso a message needs to make it into public archives before\nit goes out to subscribers. That might prevent or avoid\nsuch problems... *shrug*\n"}]}