{"thread":{"id":"52324","subject":"[PATCH 0/1] add--interactive: skip index refresh in reset patch mode","startedAt":"2019-11-23T19:56:45Z","lastAt":"2021-01-14T06:31:27Z","messageCount":20,"participants":["Nika Layzell via GitGitGadget","Junio C Hamano","Johannes Schindelin","Ævar Arnfjörð Bjarmason","Taylor Blau","胡哲宁"],"isPatch":true,"patchVersion":1,"patchTotal":1},"messages":[{"id":"386912","messageId":"pull.475.git.1574539001.gitgitgadget@gmail.com","threadId":"52324","inReplyTo":null,"subject":"[PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Nika Layzell via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-11-23T19:56:39Z","receivedAt":"2019-11-23T19:56:45Z","isPatch":true,"sender":{"key":"nika@thelayzells.com","avatar":"https://avatars.githubusercontent.com/u/1261662?v=4"},"body":"The refresh command is called from git-add--interactive to ensure that git's\nview of the worktree is up-to-date. This is necessary for most commands\nwhich use git-add--interactive, as they are interacting with the worktree,\nhowever it's not necessary for git-reset, which exclusively operates on the\nindex. This patch skips the refresh call when performing a git-reset -p,\nwhich can improve performance on large repositories which have out-of-date,\nor no, caches of the current worktree state.\n\nI chose to use the existing FILTER property of the flavour to make this\ndecision. A separate REFRESH property could be added instead.\n\nNika Layzell (1):\n add--interactive: skip index refresh in reset patch mode\n\n git-add--interactive.perl | 4 +++-\n 1 file changed, 3 insertions(+), 1 deletion(-)\n\n\nbase-commit: 5fa0f5238b0cd46cfe7f6fa76c3f526ea98148d9\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-475%2Fmystor%2Findex-only-refresh-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-475/mystor/index-only-refresh-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/475\n-- \ngitgitgadget\n"},{"id":"386913","messageId":"68f3be6ca65b3904bd4664b743fccbe1ac4e7d22.1574539001.git.gitgitgadget@gmail.com","threadId":"52324","inReplyTo":"pull.475.git.1574539001.gitgitgadget@gmail.com","subject":"[PATCH 1/1] add--interactive: skip index refresh in reset patch mode","fromName":"Nika Layzell via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-11-23T19:56:40Z","receivedAt":"2019-11-23T19:56:47Z","isPatch":true,"sender":{"key":"nika@thelayzells.com","avatar":"https://avatars.githubusercontent.com/u/1261662?v=4"},"body":"From: Nika Layzell \n\nUses the FILTER flag on patch flavours in git-add--interactive to\ndetermine if the initial index refresh call is required. It is not\nrequired for the reset patch modes, which use the 'index-only' filter,\nas they do not interact with the worktree, so do not need up-to-date\nstat information.\n\nThe refresh call can be quite expensive, especially on larger\ncheckouts or with a freshly created index file.\n\nSigned-off-by: Nika Layzell \n---\n git-add--interactive.perl | 4 +++-\n 1 file changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git a/git-add--interactive.perl b/git-add--interactive.perl\nindex c20ae9e210..cd435b197f 100755\n--- a/git-add--interactive.perl\n+++ b/git-add--interactive.perl\n@@ -1861,7 +1861,9 @@ sub main_loop {\n }\n \n process_args();\n-refresh();\n+if ($patch_mode_flavour{FILTER} ne 'index-only') {\n+\trefresh();\n+}\n if ($patch_mode_only) {\n \tpatch_update_cmd();\n }\n-- \ngitgitgadget\n"},{"id":"386931","messageId":"xmqqwobpzubw.fsf@gitster-ct.c.googlers.com","threadId":"52324","inReplyTo":"pull.475.git.1574539001.gitgitgadget@gmail.com","subject":"Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-24T06:01:23Z","receivedAt":"2019-11-24T06:01:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Nika Layzell via GitGitGadget\" writes:\n\n> The refresh command is called from git-add--interactive to ensure that git's\n> view of the worktree is up-to-date. This is necessary for most commands\n> which use git-add--interactive, as they are interacting with the worktree,\n> however it's not necessary for git-reset, which exclusively operates on the\n> index. This patch skips the refresh call when performing a git-reset -p,\n> which can improve performance on large repositories which have out-of-date,\n> or no, caches of the current worktree state.\n>\n> I chose to use the existing FILTER property of the flavour to make this\n> decision. A separate REFRESH property could be added instead.\n\nHmph, I wonder why this was sent my way. How does GGG determine\nwhom to send patches to? I, like other reviewers, prefer not to see\nearlier rounds of patches sent directly to me unless they are about\nareas that I am mostly responsible for (other patches I'll see them\nand review them on the copies sent to the mailing list anyway).\n\nCC'ing Dscho who has stakes in keeping the scripted \"add -i\" frozen,\nwhile he is rewriting it in C.\n\nThanks.\n\n>\n> Nika Layzell (1):\n> add--interactive: skip index refresh in reset patch mode\n>\n> git-add--interactive.perl | 4 +++-\n> 1 file changed, 3 insertions(+), 1 deletion(-)\n>\n>\n> base-commit: 5fa0f5238b0cd46cfe7f6fa76c3f526ea98148d9\n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-475%2Fmystor%2Findex-only-refresh-v1\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-475/mystor/index-only-refresh-v1\n> Pull-Request: https://github.com/gitgitgadget/git/pull/475\n"},{"id":"386994","messageId":"nycvar.QRO.7.76.6.1911251523530.31080@tvgsbejvaqbjf.bet","threadId":"52324","inReplyTo":"xmqqwobpzubw.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-11-25T14:24:50Z","receivedAt":"2019-11-25T14:25:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Sun, 24 Nov 2019, Junio C Hamano wrote:\n\n> \"Nika Layzell via GitGitGadget\" writes:\n>\n> > The refresh command is called from git-add--interactive to ensure that git's\n> > view of the worktree is up-to-date. This is necessary for most commands\n> > which use git-add--interactive, as they are interacting with the worktree,\n> > however it's not necessary for git-reset, which exclusively operates on the\n> > index. This patch skips the refresh call when performing a git-reset -p,\n> > which can improve performance on large repositories which have out-of-date,\n> > or no, caches of the current worktree state.\n> >\n> > I chose to use the existing FILTER property of the flavour to make this\n> > decision. A separate REFRESH property could be added instead.\n>\n> Hmph, I wonder why this was sent my way. How does GGG determine\n> whom to send patches to? I, like other reviewers, prefer not to see\n> earlier rounds of patches sent directly to me unless they are about\n> areas that I am mostly responsible for (other patches I'll see them\n> and review them on the copies sent to the mailing list anyway).\n>\n> CC'ing Dscho who has stakes in keeping the scripted \"add -i\" frozen,\n> while he is rewriting it in C.\n\nThanks for pinging me!\n\nAs it were, I was aware of this effort, and I am quite happy about it (and\nof course I will adjust my patch series accordingly).\n\nThank you,\nDscho\n\n>\n> Thanks.\n>\n> >\n> > Nika Layzell (1):\n> > add--interactive: skip index refresh in reset patch mode\n> >\n> > git-add--interactive.perl | 4 +++-\n> > 1 file changed, 3 insertions(+), 1 deletion(-)\n> >\n> >\n> > base-commit: 5fa0f5238b0cd46cfe7f6fa76c3f526ea98148d9\n> > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-475%2Fmystor%2Findex-only-refresh-v1\n> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-475/mystor/index-only-refresh-v1\n> > Pull-Request: https://github.com/gitgitgadget/git/pull/475\n>\n"},{"id":"386998","messageId":"nycvar.QRO.7.76.6.1911251543430.31080@tvgsbejvaqbjf.bet","threadId":"52324","inReplyTo":"nycvar.QRO.7.76.6.1911251523530.31080@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-11-25T14:45:53Z","receivedAt":"2019-11-25T14:46:16Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Mon, 25 Nov 2019, Johannes Schindelin wrote:\n\n> On Sun, 24 Nov 2019, Junio C Hamano wrote:\n>\n> > \"Nika Layzell via GitGitGadget\" writes:\n> >\n> > > The refresh command is called from git-add--interactive to ensure that git's\n> > > view of the worktree is up-to-date. This is necessary for most commands\n> > > which use git-add--interactive, as they are interacting with the worktree,\n> > > however it's not necessary for git-reset, which exclusively operates on the\n> > > index. This patch skips the refresh call when performing a git-reset -p,\n> > > which can improve performance on large repositories which have out-of-date,\n> > > or no, caches of the current worktree state.\n> > >\n> > > I chose to use the existing FILTER property of the flavour to make this\n> > > decision. A separate REFRESH property could be added instead.\n> >\n> > Hmph, I wonder why this was sent my way. How does GGG determine\n> > whom to send patches to? I, like other reviewers, prefer not to see\n> > earlier rounds of patches sent directly to me unless they are about\n> > areas that I am mostly responsible for (other patches I'll see them\n> > and review them on the copies sent to the mailing list anyway).\n\nOops, I forgot to address this. The reason why this is sent your way is\nthat you are the Git maintainer, and as such, GitGitGadget sends _all_ Git\npatches your way (except the Git GUI ones).\n\nThe reason for this is that this is the suggested way, as per\nhttps://git-scm.com/docs/SubmittingPatches#patch-flow:\n\n> 5. The list forms consensus that the last round of your patch is good. Send\n> it to the maintainer and cc the list.\n\nCiao,\nDscho\n\n> > CC'ing Dscho who has stakes in keeping the scripted \"add -i\" frozen,\n> > while he is rewriting it in C.\n>\n> Thanks for pinging me!\n>\n> As it were, I was aware of this effort, and I am quite happy about it (and\n> of course I will adjust my patch series accordingly).\n>\n> Thank you,\n> Dscho\n>\n> >\n> > Thanks.\n> >\n> > >\n> > > Nika Layzell (1):\n> > > add--interactive: skip index refresh in reset patch mode\n> > >\n> > > git-add--interactive.perl | 4 +++-\n> > > 1 file changed, 3 insertions(+), 1 deletion(-)\n> > >\n> > >\n> > > base-commit: 5fa0f5238b0cd46cfe7f6fa76c3f526ea98148d9\n> > > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-475%2Fmystor%2Findex-only-refresh-v1\n> > > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-475/mystor/index-only-refresh-v1\n> > > Pull-Request: https://github.com/gitgitgadget/git/pull/475\n> >\n>\n"},{"id":"387034","messageId":"xmqqtv6rwidc.fsf@gitster-ct.c.googlers.com","threadId":"52324","inReplyTo":"nycvar.QRO.7.76.6.1911251523530.31080@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-26T01:12:31Z","receivedAt":"2019-11-26T01:13:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> CC'ing Dscho who has stakes in keeping the scripted \"add -i\" frozen,\n>> while he is rewriting it in C.\n>\n> Thanks for pinging me!\n>\n> As it were, I was aware of this effort, and I am quite happy about it (and\n> of course I will adjust my patch series accordingly).\n\nThanks, both.\n"},{"id":"387035","messageId":"xmqqpnhfwibn.fsf@gitster-ct.c.googlers.com","threadId":"52324","inReplyTo":"nycvar.QRO.7.76.6.1911251543430.31080@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-26T01:13:32Z","receivedAt":"2019-11-26T01:13:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> > Hmph, I wonder why this was sent my way. How does GGG determine\n>> > whom to send patches to? I, like other reviewers, prefer not to see\n>> > earlier rounds of patches sent directly to me unless they are about\n>> > areas that I am mostly responsible for (other patches I'll see them\n>> > and review them on the copies sent to the mailing list anyway).\n>\n> Oops, I forgot to address this. The reason why this is sent your way is\n> that you are the Git maintainer, and as such, GitGitGadget sends _all_ Git\n> patches your way (except the Git GUI ones).\n>\n> The reason for this is that this is the suggested way, as per\n> https://git-scm.com/docs/SubmittingPatches#patch-flow:\n>\n>> 5. The list forms consensus that the last round of your patch is good. Send\n>> it to the maintainer and cc the list.\n\nYeah, but as far as I can tell, this is the _first_ round the list\nsees this topic, which by definition would not have any consensus\n;-)\n"},{"id":"413694","messageId":"nycvar.QRO.7.76.6.2101071517260.2213@tvgsbejvaqbjf.bet","threadId":"52324","inReplyTo":"xmqqpnhfwibn.fsf@gitster-ct.c.googlers.com","subject":"Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-01-07T14:18:28Z","receivedAt":"2021-01-07T14:20:19Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Tue, 26 Nov 2019, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n>\n> >> > Hmph, I wonder why this was sent my way. How does GGG determine\n> >> > whom to send patches to? I, like other reviewers, prefer not to see\n> >> > earlier rounds of patches sent directly to me unless they are about\n> >> > areas that I am mostly responsible for (other patches I'll see them\n> >> > and review them on the copies sent to the mailing list anyway).\n> >\n> > Oops, I forgot to address this. The reason why this is sent your way is\n> > that you are the Git maintainer, and as such, GitGitGadget sends _all_ Git\n> > patches your way (except the Git GUI ones).\n> >\n> > The reason for this is that this is the suggested way, as per\n> > https://git-scm.com/docs/SubmittingPatches#patch-flow:\n> >\n> >> 5. The list forms consensus that the last round of your patch is good. Send\n> >> it to the maintainer and cc the list.\n>\n> Yeah, but as far as I can tell, this is the _first_ round the list\n> sees this topic, which by definition would not have any consensus\n> ;-)\n\nI thought about it for over a year and still have no clue how we could\nteach GitGitGadget to Cc: you when it is appropriate, not without putting\nthe burden on any human being.\n\nCiao,\nDscho\n"},{"id":"413697","messageId":"87wnwordzh.fsf@evledraar.gmail.com","threadId":"52324","inReplyTo":"nycvar.QRO.7.76.6.2101071517260.2213@tvgsbejvaqbjf.bet","subject":"Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-01-07T14:57:54Z","receivedAt":"2021-01-07T14:58:38Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Jan 07 2021, Johannes Schindelin wrote:\n\n> Hi Junio,\n>\n> On Tue, 26 Nov 2019, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>>\n>> >> > Hmph, I wonder why this was sent my way. How does GGG determine\n>> >> > whom to send patches to? I, like other reviewers, prefer not to see\n>> >> > earlier rounds of patches sent directly to me unless they are about\n>> >> > areas that I am mostly responsible for (other patches I'll see them\n>> >> > and review them on the copies sent to the mailing list anyway).\n>> >\n>> > Oops, I forgot to address this. The reason why this is sent your way is\n>> > that you are the Git maintainer, and as such, GitGitGadget sends _all_ Git\n>> > patches your way (except the Git GUI ones).\n>> >\n>> > The reason for this is that this is the suggested way, as per\n>> > https://git-scm.com/docs/SubmittingPatches#patch-flow:\n>> >\n>> >> 5. The list forms consensus that the last round of your patch is good. Send\n>> >> it to the maintainer and cc the list.\n>>\n>> Yeah, but as far as I can tell, this is the _first_ round the list\n>> sees this topic, which by definition would not have any consensus\n>> ;-)\n>\n> I thought about it for over a year and still have no clue how we could\n> teach GitGitGadget to Cc: you when it is appropriate, not without putting\n> the burden on any human being.\n\nThat message is from November 2019, didn't you later fix this in January\n2020 here: https://github.com/gitgitgadget/gitgitgadget/commit/b2221f4 ?\n\nI.e. now users need to explicitly add \"cc: gitster@pobox.com\" to the\ndescription, no? So isn't in the same as for us who use the\nformat-patch/send-email flow in this regard?\n"},{"id":"413701","messageId":"nycvar.QRO.7.76.6.2101071718470.2213@tvgsbejvaqbjf.bet","threadId":"52324","inReplyTo":"87wnwordzh.fsf@evledraar.gmail.com","subject":"Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-01-07T16:20:22Z","receivedAt":"2021-01-07T16:22:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ævar,\n\nOn Thu, 7 Jan 2021, Ævar Arnfjörð Bjarmason wrote:\n\n> On Thu, Jan 07 2021, Johannes Schindelin wrote:\n>\n> > Hi Junio,\n> >\n> > On Tue, 26 Nov 2019, Junio C Hamano wrote:\n> >\n> >> Johannes Schindelin writes:\n> >>\n> >> >> > Hmph, I wonder why this was sent my way. How does GGG determine\n> >> >> > whom to send patches to? I, like other reviewers, prefer not to see\n> >> >> > earlier rounds of patches sent directly to me unless they are about\n> >> >> > areas that I am mostly responsible for (other patches I'll see them\n> >> >> > and review them on the copies sent to the mailing list anyway).\n> >> >\n> >> > Oops, I forgot to address this. The reason why this is sent your way is\n> >> > that you are the Git maintainer, and as such, GitGitGadget sends _all_ Git\n> >> > patches your way (except the Git GUI ones).\n> >> >\n> >> > The reason for this is that this is the suggested way, as per\n> >> > https://git-scm.com/docs/SubmittingPatches#patch-flow:\n> >> >\n> >> >> 5. The list forms consensus that the last round of your patch is good. Send\n> >> >> it to the maintainer and cc the list.\n> >>\n> >> Yeah, but as far as I can tell, this is the _first_ round the list\n> >> sees this topic, which by definition would not have any consensus\n> >> ;-)\n> >\n> > I thought about it for over a year and still have no clue how we could\n> > teach GitGitGadget to Cc: you when it is appropriate, not without putting\n> > the burden on any human being.\n>\n> That message is from November 2019, didn't you later fix this in January\n> 2020 here: https://github.com/gitgitgadget/gitgitgadget/commit/b2221f4 ?\n\nI would not call that a fix. As mentioned, I could not come up with a way\nto Cc: Junio only when appropriate in a way that wouldn't surprise new\nusers. So yes, I disabled the auto-Cc:ing, with no appropriate\nreplacement.\n\n> I.e. now users need to explicitly add \"cc: gitster@pobox.com\" to the\n> description, no? So isn't in the same as for us who use the\n> format-patch/send-email flow in this regard?\n\nRight. And that is... intuitive? If you have to read the manual, the\ndesign is broken.\n\nCiao,\nDscho\n"},{"id":"413744","messageId":"xmqqft3cl9rw.fsf@gitster.c.googlers.com","threadId":"52324","inReplyTo":"nycvar.QRO.7.76.6.2101071718470.2213@tvgsbejvaqbjf.bet","subject":"Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-07T21:25:23Z","receivedAt":"2021-01-07T21:26:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I would not call that a fix. As mentioned, I could not come up with a way\n> to Cc: Junio only when appropriate in a way that wouldn't surprise new\n> users. So yes, I disabled the auto-Cc:ing, with no appropriate\n> replacement.\n>\n>> I.e. now users need to explicitly add \"cc: gitster@pobox.com\" to the\n>> description, no? So isn't in the same as for us who use the\n>> format-patch/send-email flow in this regard?\n>\n> Right. And that is... intuitive? If you have to read the manual, the\n> design is broken.\n\nLet's step back and think when a patch submitter wants to CC\nanybody. People explicitly Cc area experts when touching certain\npart of the codebase, so that they can ask for their input. People\nalso explicitly Cc the maintainer when they see the reviewers\nreached a consensus that it is a good idea to apply the patch.\nThese CC has value only because they came from conscious decision\nby the submitter---they actively asks for help and that nudges the\nrecipient of CC to help them.\n\nEven without such Cc:, stakeholders (both area experts and the\nmaintainer) often notice noteworthy patches and discussions, so\nbetween having CC that is thrown around freely without thought and\ncrowds recipient's inbox and not having such thoughtless CC at all,\nthe latter is vastly preferred. The former just diminishes the\nvalue of Cc that are added manually by thoughtful people. \n\nIn short, \"now users need to explicitly add\" is a GOOD thing. \n\nThe best is to have only thoughtful CC, the second best is not to\nhave automated CC at all, and the worst is always throw automated CC\nto hurt others who try to make CC mean something by making judicious\nuse of it.\n\nHaving said all that.\n\nWe may not be able to automate the thinking part to decide when\nsubmitter may want to get help, but an automation can help by giving\nthe submitter cues and clues when to ask for help and from whom.\n\nIs there a point in the end-user experience flow, starting at the\ntime when they push their proposed change to their repository, throw\na pull request at GitHub, say \"/submit\", and then GGG finally sends\nout a patch e-mail, where the GGG machinery can inspect the change\nand give the user (preferrably before the user says /submit) a hint\nthat says \"you may want to add Cc: to these people in such and such\ncase, and if you think the situation falls into these cases, tell me\nso by saying /submit-with-suggested-cc instead of the usual\n/submit\"?\n\nAnd \"these people\" may include those who touched the affected code\nwithin the past 6 months, and it may also include the maintainer\nwhen the pull request is in its second or later iteration.\n\nThanks.\n"},{"id":"413822","messageId":"nycvar.QRO.7.76.6.2101081534380.2213@tvgsbejvaqbjf.bet","threadId":"52324","inReplyTo":"xmqqft3cl9rw.fsf@gitster.c.googlers.com","subject":"Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-01-08T14:56:20Z","receivedAt":"2021-01-08T14:57:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Thu, 7 Jan 2021, Junio C Hamano wrote:\n\n> We may not be able to automate the thinking part to decide when\n> submitter may want to get help, but an automation can help by giving\n> the submitter cues and clues when to ask for help and from whom.\n\nI fear that we're striking the balance on the side of expecting too much\nknowledge about project-specific lore from contributors.\n\nMy goal with GitGitGadget was to allow competent contributors to focus on\naddressing their pet peeve with Git, to produce a stellar patch with an\noutstanding description and get that integrated into the next major Git\nversion, and not have to learn about the culture and mechanics of our\npatch review process for what may very well be their single contribution\nto Git.\n\nJust look at the wall of text GitGitGadget first-time users _already_ have\nto read through, and it does not even catch half of what is relevant for\nevery single contributor:\nhttps://github.com/gitgitgadget/gitgitgadget/blob/HEAD/res/WELCOME.md\n\nNote that this wall of text does not even begin to answer questions such\nas \"how do I know when this patch is accepted?\".\n\nThe suggestion that the contributor should Cc: you explicitly when the\ncontribution is supposedly ready to advance (according to a set of rules\nthat is not formalized anywhere that I know of) could potentially be added\nto that wall of text, but I doubt that it will make it easier to\ncontribute even for the most advanced and dedicated software engineers.\n\n> Is there a point in the end-user experience flow, starting at the\n> time when they push their proposed change to their repository, throw\n> a pull request at GitHub, say \"/submit\", and then GGG finally sends\n> out a patch e-mail, where the GGG machinery can inspect the change\n> and give the user (preferrably before the user says /submit) a hint\n> that says \"you may want to add Cc: to these people in such and such\n> case, and if you think the situation falls into these cases, tell me\n> so by saying /submit-with-suggested-cc instead of the usual\n> /submit\"?\n>\n> And \"these people\" may include those who touched the affected code\n> within the past 6 months, and it may also include the maintainer\n> when the pull request is in its second or later iteration.\n\nWe already have a ticket suggesting to add reviewers:\nhttps://github.com/gitgitgadget/gitgitgadget/issues/219\n\nWith this suggestion, too, we could go and extend that wall of text even\nfurther and expect contributors to just know what they are supposed to do.\nBut I don't see how that would make this process more inviting to new\ncontributors.\n\nBTW I get the sense that many Git mailing list regulars have this idea\nthat making the review process easier for one-time contributors would\ninvite too many low-quality contributions. However, I see the exact\nopposite: professional software engineers I talk to refuse to jump through\nall those hoops, even if they would be quite capable of producing a\nstellar patch within no time. At the same time I see a lot of less\nexperienced developers delighting in the struggle^Wchallenge to set up\n`git send-email` correctly _just_ to earn bragging rights to have their\ntypo fix in Git's commit history. I am exaggerating here, of course, to\nmake a point. And I think this is a very valid point. We lose\ncontributions (and potential future reviewers) because we make it harder\nthan necessary to contribute to Git.\n\nCiao,\nDscho\n"},{"id":"413868","messageId":"xmqq8s93i506.fsf@gitster.c.googlers.com","threadId":"52324","inReplyTo":"nycvar.QRO.7.76.6.2101081534380.2213@tvgsbejvaqbjf.bet","subject":"Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-08T19:48:57Z","receivedAt":"2021-01-08T19:49:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> But I don't see how that would make this process more inviting to new\n> contributors.\n\nAppearing to be inviting should not be our primary goal. \n\nInstead, the goal should be to make it easier to contribute quality\npatches. By doing so, the smooth experience may attract more new\npeople, which may end up to be \"inviting\" in the end, but that is as\na side effect.\n\n> BTW I get the sense that many Git mailing list regulars have this idea\n> that making the review process easier for one-time contributors would\n> invite too many low-quality contributions.\n\nI don't get such a sense at all.\n\nSure, if GGG or any other mechanism encourages spamming the list\nwith low-quality patches, that may harm our productivity, but that\nis not what we are doing. And I do not see how it can be a source\nof low-quality contributions to send patches that by default do not\nCC them to random people when the sender does not know when it is\nappropriate to do so. Sure, if the patches asked for attention from\nappropriate reviewers (the maintainer included), it might get more\nresponses, but we more often review patches that are only sent to\nthe list than those that are sent directly to us via Cc _anyway_.\n\nOn the other hand, inviting more new people to CC reviewers whose\nmailboxes are already full when the patches are not yet ready would\nharm productivity of recipients of such patches.\n\nOne attribute of a quality patch is that it is CC'ed to the right\npeople and at the right time.\n"},{"id":"413887","messageId":"X/i7zvgMJHfOmyZG@nand.local","threadId":"52324","inReplyTo":"nycvar.QRO.7.76.6.2101081534380.2213@tvgsbejvaqbjf.bet","subject":"Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2021-01-08T20:08:46Z","receivedAt":"2021-01-08T20:09:32Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Fri, Jan 08, 2021 at 03:56:20PM +0100, Johannes Schindelin wrote:\n> Hi Junio,\n>\n> On Thu, 7 Jan 2021, Junio C Hamano wrote:\n>\n> > We may not be able to automate the thinking part to decide when\n> > submitter may want to get help, but an automation can help by giving\n> > the submitter cues and clues when to ask for help and from whom.\n>\n> I fear that we're striking the balance on the side of expecting too much\n> knowledge about project-specific lore from contributors.\n\nI think that this could be reasonably addressed. When someone opens a PR\n(but before the hit /submit), GGG could say:\n\n Your change touches these files, and so suggested reviewers include\n X, Y, Z. When you believe your submission is in its last round,\n please also include the maintainer, M.\n\n> We already have a ticket suggesting to add reviewers:\n> https://github.com/gitgitgadget/gitgitgadget/issues/219\n>\n> With this suggestion, too, we could go and extend that wall of text even\n> further and expect contributors to just know what they are supposed to do.\n> But I don't see how that would make this process more inviting to new\n> contributors.\n\nYeah, I agree that adding this as a separate step does not make sense,\nsince it's hard to discover such things (especially by individuals who\nmerely want to send a single contribution to the project). Having this\nhappen automatically upon creating a PR would make more sense to me.\n\nThanks,\nTaylor\n"},{"id":"413961","messageId":"nycvar.QRO.7.76.6.2101101301280.56@tvgsbejvaqbjf.bet","threadId":"52324","inReplyTo":"xmqq8s93i506.fsf@gitster.c.googlers.com","subject":"Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-01-10T12:02:52Z","receivedAt":"2021-01-10T12:04:31Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Fri, 8 Jan 2021, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n>\n> One attribute of a quality patch is that it is CC'ed to the right\n> people and at the right time.\n\nThat's like saying that a quality guest in my house is one who does not\nhave to ask where the bathroom is.\n\nI want the Git project to be more inviting than that.\n\nCiao,\nDscho\n"},{"id":"413963","messageId":"nycvar.QRO.7.76.6.2101101306310.56@tvgsbejvaqbjf.bet","threadId":"52324","inReplyTo":"X/i7zvgMJHfOmyZG@nand.local","subject":"Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-01-10T12:21:38Z","receivedAt":"2021-01-10T12:23:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Taylor,\n\nOn Fri, 8 Jan 2021, Taylor Blau wrote:\n\n> On Fri, Jan 08, 2021 at 03:56:20PM +0100, Johannes Schindelin wrote:\n> >\n> > On Thu, 7 Jan 2021, Junio C Hamano wrote:\n> >\n> > > We may not be able to automate the thinking part to decide when\n> > > submitter may want to get help, but an automation can help by giving\n> > > the submitter cues and clues when to ask for help and from whom.\n> >\n> > I fear that we're striking the balance on the side of expecting too much\n> > knowledge about project-specific lore from contributors.\n>\n> I think that this could be reasonably addressed. When someone opens a PR\n> (but before the hit /submit), GGG could say:\n>\n> Your change touches these files, and so suggested reviewers include\n> X, Y, Z. When you believe your submission is in its last round,\n> please also include the maintainer, M.\n\nThat is an option.\n\nIs it the best option to reach the goal where competent software engineers\ncan focus on improving Git's source code?\n\nMaybe it is not possible do automate what I wish for.\n\n> > We already have a ticket suggesting to add reviewers:\n> > https://github.com/gitgitgadget/gitgitgadget/issues/219\n> >\n> > With this suggestion, too, we could go and extend that wall of text even\n> > further and expect contributors to just know what they are supposed to do.\n> > But I don't see how that would make this process more inviting to new\n> > contributors.\n>\n> Yeah, I agree that adding this as a separate step does not make sense,\n> since it's hard to discover such things (especially by individuals who\n> merely want to send a single contribution to the project). Having this\n> happen automatically upon creating a PR would make more sense to me.\n\nRight.\n\nI always have this contribution in mind: Improve the readability of `log\n--graph` output (https://github.com/gitgitgadget/git/pull/383)\n\nThis was an excellent contribution. I doubt that we would have received it\nwithout GitGitGadget, as the contributor could really focus on the code\nchange instead of the contribution logistics.\n\nWe did not exactly make it easy, and I fear that we are losing a lot of\npotential contributions because of that.\n\nFor example, Git is often ridiculed for being hard to use, and I can\nunderstand. There has been research into ways to improve that, but little\nof that research resulted in contributions on the Git mailing list. I\nwould not at all be surprised if that was because of the review process we\nput up.\n\nUsability is only one area where I think we would benefit from attracting\ntalent. Accessibility is another one. Or UI improvements (consistency,\nself-explanatory navigation, etc). Or...\n\nCiao,\nDscho\n"},{"id":"413985","messageId":"xmqq8s90a6li.fsf@gitster.c.googlers.com","threadId":"52324","inReplyTo":"nycvar.QRO.7.76.6.2101101306310.56@tvgsbejvaqbjf.bet","subject":"Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-10T20:18:33Z","receivedAt":"2021-01-10T20:19:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi Taylor,\n>\n> On Fri, 8 Jan 2021, Taylor Blau wrote:\n> ...\n>> I think that this could be reasonably addressed. When someone opens a PR\n>> (but before the hit /submit), GGG could say:\n>>\n>> Your change touches these files, and so suggested reviewers include\n>> X, Y, Z. When you believe your submission is in its last round,\n>> please also include the maintainer, M.\n>\n> That is an option.\n\nAs Taylor created the above suggestion as a counter-proposal, I can\nsee that I apparently did not express what I meant very well, when I\nsaid:\n\n Is there a point in the end-user experience flow, starting at\n the time when they push their proposed change to their\n repository, throw a pull request at GitHub, say \"/submit\", and\n then GGG finally sends out a patch e-mail, where the GGG\n machinery can inspect the change and give the user (preferrably\n before the user says /submit) a hint that says \"you may want to\n add Cc: to these people in such and such case, and if you think\n the situation falls into these cases, tell me so by saying\n /submit-with-suggested-cc instead of the usual /submit\"?\n\nWhat Taylor suggested, and what you seem to be agreeing to, is\nexactly what I had in mind when I wrote the above in my message. \n\nSo perhaps we three are on the same page from the beginning ;-)\n\nLooking forward to see a new feature that helps contributors to more\neasily ask help from appropriate people.\n\nThanks.\n\n"},{"id":"414068","messageId":"X/ykg4rEDDpWdZN9@nand.local","threadId":"52324","inReplyTo":"xmqq8s90a6li.fsf@gitster.c.googlers.com","subject":"Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2021-01-11T19:18:27Z","receivedAt":"2021-01-11T19:19:17Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Sun, Jan 10, 2021 at 12:18:33PM -0800, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n>\n> > Hi Taylor,\n> >\n> > On Fri, 8 Jan 2021, Taylor Blau wrote:\n> > ...\n> >> I think that this could be reasonably addressed. When someone opens a PR\n> >> (but before the hit /submit), GGG could say:\n> >>\n> >> Your change touches these files, and so suggested reviewers include\n> >> X, Y, Z. When you believe your submission is in its last round,\n> >> please also include the maintainer, M.\n> >\n> > That is an option.\n>\n> As Taylor created the above suggestion as a counter-proposal, I can\n> see that I apparently did not express what I meant very well, when I\n> said:\n\n...or that I must have not read your email which quite clearly states\nwhat I was thinking of, too. ;-).\n\n> So perhaps we three are on the same page from the beginning ;-)\n\nI think so.\n\nThanks,\nTaylor\n"},{"id":"414234","messageId":"xmqqsg75zqo0.fsf@gitster.c.googlers.com","threadId":"52324","inReplyTo":"X/ykg4rEDDpWdZN9@nand.local","subject":"Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-12T23:22:39Z","receivedAt":"2021-01-12T23:23:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> On Sun, Jan 10, 2021 at 12:18:33PM -0800, Junio C Hamano wrote:\n>\n>> As Taylor created the above suggestion as a counter-proposal, I can\n>> see that I apparently did not express what I meant very well, when I\n>> said:\n>\n> ...or that I must have not read your email which quite clearly states\n> what I was thinking of, too. ;-).\n\nSeeing that Dscho had a negative reaction to my rendering of my\nthought while showing positive one towards yours, I see that what I\nwrote wasn't clear enough to be understood to at least two people.\n\nThanks for clearly illustrating a possible end user experience that\nis desiable.\n"},{"id":"414326","messageId":"CAOLTT8QqXOgtqxCa=yTz=GgBz0f00AVypZ5y=m+hSTUdhBMEfg@mail.gmail.com","threadId":"52324","inReplyTo":"xmqq8s90a6li.fsf@gitster.c.googlers.com","subject":"Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode","fromName":"胡哲宁","fromEmail":"adlternative@gmail.com","sentAt":"2021-01-14T06:32:04Z","receivedAt":"2021-01-14T06:31:27Z","isPatch":true,"sender":{"key":"adlternative@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58138461?v=4"},"body":"> Looking forward to see a new feature that helps contributors to more\n> easily ask help from appropriate people.\n\nI'm a novice with lots of interest but lots of problems.\n\nA week ago, I made the following submission:\nhttps://public-inbox.org/git/pull.832.v2.git.1610116600.gitgitgadget@gmail.com/\nhttps://public-inbox.org/git/0261e5d245ef0a5b9a717be1bc03492d7bc06c5e.1610116600.git.gitgitgadget@gmail.com/\nhttps://public-inbox.org/git/a09a5098aa66ea0ed89fe0fcde3f016b4a65814d.1610116600.git.gitgitgadget@gmail.com/\n\nNow I really want to find the right person to reply to me, but it\nseems that no one has answered me yet.\nDo I have some mistakes in the use of GIT gadgets? Please tell me and\nI will correct it.\n\nThanks.\n--\nZheNing Hu\n"}]}