add--interactive: skip index refresh in reset patch mode
cover add--interactive: skip index refresh in reset patch mode
The refresh command is called from git-add--interactive to ensure that git's view of the worktree is up-to-date. This is necessary for most commands which use git-add--interactive, as they are interacting with the worktree, however it's not necessary for git-reset, which exclusively operates on the index. This patch skips the refresh call when performing a git-reset -p, which can improve performance on large repositories which have out-of-date, or no, caches of the current worktree state.
I chose to use the existing FILTER property of the flavour to make this decision. A separate REFRESH property could be added instead.
Nika Layzell (1):
add--interactive: skip index refresh in reset patch mode
git-add--interactive.perl | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
base-commit: 5fa0f5238b0cd46cfe7f6fa76c3f526ea98148d9
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-475%2Fmystor%2Findex-only-refresh-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-475/mystor/index-only-refresh-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/475
Signature · 1 line
gitgitgadget
PATCH 1/1 add--interactive: skip index refresh in reset patch mode
From: Nika Layzell <[email protected]>
Uses the FILTER flag on patch flavours in git-add--interactive to determine if the initial index refresh call is required. It is not required for the reset patch modes, which use the 'index-only' filter, as they do not interact with the worktree, so do not need up-to-date stat information.
The refresh call can be quite expensive, especially on larger checkouts or with a freshly created index file.
--- git-add--interactive.perl | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
git-add--interactive.perl +3 -1
@@ -1861,7 +1861,9 @@ sub main_loop { } process_args(); -refresh(); +if ($patch_mode_flavour{FILTER} ne 'index-only') { + refresh(); +} if ($patch_mode_only) { patch_update_cmd(); }
Signature · 1 line
gitgitgadget
Quoted 10 lines · Nika Layzell via GitGitGadget
The refresh command is called from git-add--interactive to ensure that git's view of the worktree is up-to-date. This is necessary for most commands which use git-add--interactive, as they are interacting with the worktree, however it's not necessary for git-reset, which exclusively operates on the index. This patch skips the refresh call when performing a git-reset -p, which can improve performance on large repositories which have out-of-date, or no, caches of the current worktree state.
I chose to use the existing FILTER property of the flavour to make this decision. A separate REFRESH property could be added instead.
Hmph, I wonder why this was sent my way. How does GGG determine whom to send patches to? I, like other reviewers, prefer not to see earlier rounds of patches sent directly to me unless they are about areas that I am mostly responsible for (other patches I'll see them and review them on the copies sent to the mailing list anyway).
CC'ing Dscho who has stakes in keeping the scripted "add -i" frozen, while he is rewriting it in C.
Thanks.
Quoted 12 lines
Nika Layzell (1):
add--interactive: skip index refresh in reset patch modegit-add--interactive.perl | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)base-commit:
5fa0f5238b0cd46cfe7f6fa76c3f526ea98148d9
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-475%2Fmystor%2Findex-only-refresh-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-475/mystor/index-only-refresh-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/475
Hi Junio,
Quoted 13 lines · Junio C Hamano
Quoted 10 lines · Nika Layzell via GitGitGadget
The refresh command is called from git-add--interactive to ensure that git's view of the worktree is up-to-date. This is necessary for most commands which use git-add--interactive, as they are interacting with the worktree, however it's not necessary for git-reset, which exclusively operates on the index. This patch skips the refresh call when performing a git-reset -p, which can improve performance on large repositories which have out-of-date, or no, caches of the current worktree state.
I chose to use the existing FILTER property of the flavour to make this decision. A separate REFRESH property could be added instead.
Quoted 8 lines
Hmph, I wonder why this was sent my way. How does GGG determine whom to send patches to? I, like other reviewers, prefer not to see earlier rounds of patches sent directly to me unless they are about areas that I am mostly responsible for (other patches I'll see them and review them on the copies sent to the mailing list anyway).
CC'ing Dscho who has stakes in keeping the scripted "add -i" frozen, while he is rewriting it in C.
Thanks for pinging me!
As it were, I was aware of this effort, and I am quite happy about it (and of course I will adjust my patch series accordingly).
Thank you,
Dscho
Quoted 16 lines
Thanks.
Quoted 12 lines
Nika Layzell (1):
add--interactive: skip index refresh in reset patch modegit-add--interactive.perl | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)base-commit:
5fa0f5238b0cd46cfe7f6fa76c3f526ea98148d9
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-475%2Fmystor%2Findex-only-refresh-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-475/mystor/index-only-refresh-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/475
Hi Junio,
Quoted 12 lines · Johannes Schindelin
Quoted 10 lines · Junio C Hamano
Quoted 8 lines · Nika Layzell via GitGitGadget
The refresh command is called from git-add--interactive to ensure that git's view of the worktree is up-to-date. This is necessary for most commands which use git-add--interactive, as they are interacting with the worktree, however it's not necessary for git-reset, which exclusively operates on the index. This patch skips the refresh call when performing a git-reset -p, which can improve performance on large repositories which have out-of-date, or no, caches of the current worktree state.
Quoted 8 lines
Quoted 8 lines
Quoted 2 lines
I chose to use the existing FILTER property of the flavour to make this decision. A separate REFRESH property could be added instead.
Hmph, I wonder why this was sent my way. How does GGG determine whom to send patches to? I, like other reviewers, prefer not to see earlier rounds of patches sent directly to me unless they are about areas that I am mostly responsible for (other patches I'll see them and review them on the copies sent to the mailing list anyway).
Oops, I forgot to address this. The reason why this is sent your way is that you are the Git maintainer, and as such, GitGitGadget sends _all_ Git patches your way (except the Git GUI ones).
The reason for this is that this is the suggested way, as per
https://git-scm.com/docs/SubmittingPatches#patch-flow:
Quoted 2 lines
5. The list forms consensus that the last round of your patch is good. Send it to the maintainer and cc the list.
Ciao,
Dscho
Quoted 28 lines
Quoted 2 lines
CC'ing Dscho who has stakes in keeping the scripted "add -i" frozen, while he is rewriting it in C.
Thanks for pinging me!
As it were, I was aware of this effort, and I am quite happy about it (and of course I will adjust my patch series accordingly).
Thank you,
DschoQuoted 16 lines
Thanks.
Quoted 12 lines
Nika Layzell (1):
add--interactive: skip index refresh in reset patch modegit-add--interactive.perl | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)base-commit:
5fa0f5238b0cd46cfe7f6fa76c3f526ea98148d9
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-475%2Fmystor%2Findex-only-refresh-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-475/mystor/index-only-refresh-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/475
Quoted 7 lines · Johannes Schindelin
Quoted 2 lines
CC'ing Dscho who has stakes in keeping the scripted "add -i" frozen, while he is rewriting it in C.
Thanks for pinging me!
As it were, I was aware of this effort, and I am quite happy about it (and of course I will adjust my patch series accordingly).
Thanks, both.
Quoted 6 lines · Johannes Schindelin
Quoted 5 lines
Quoted 5 lines
Hmph, I wonder why this was sent my way. How does GGG determine whom to send patches to? I, like other reviewers, prefer not to see earlier rounds of patches sent directly to me unless they are about areas that I am mostly responsible for (other patches I'll see them and review them on the copies sent to the mailing list anyway).
Quoted 9 lines
Oops, I forgot to address this. The reason why this is sent your way is that you are the Git maintainer, and as such, GitGitGadget sends _all_ Git patches your way (except the Git GUI ones).
The reason for this is that this is the suggested way, as per
https://git-scm.com/docs/SubmittingPatches#patch-flow:Quoted 2 lines
5. The list forms consensus that the last round of your patch is good. Send it to the maintainer and cc the list.
Yeah, but as far as I can tell, this is the _first_ round the list sees this topic, which by definition would not have any consensus ;-)
Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
Hi Junio,
Quoted 15 lines · Junio C Hamano
Quoted 13 lines · Johannes Schindelin
Quoted 5 lines
Quoted 5 lines
Hmph, I wonder why this was sent my way. How does GGG determine whom to send patches to? I, like other reviewers, prefer not to see earlier rounds of patches sent directly to me unless they are about areas that I am mostly responsible for (other patches I'll see them and review them on the copies sent to the mailing list anyway).
Oops, I forgot to address this. The reason why this is sent your way is that you are the Git maintainer, and as such, GitGitGadget sends _all_ Git patches your way (except the Git GUI ones).
The reason for this is that this is the suggested way, as per
https://git-scm.com/docs/SubmittingPatches#patch-flow:
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
5. The list forms consensus that the last round of your patch is good. Send it to the maintainer and cc the list.
Yeah, but as far as I can tell, this is the _first_ round the list sees this topic, which by definition would not have any consensus ;-)
I thought about it for over a year and still have no clue how we could teach GitGitGadget to Cc: you when it is appropriate, not without putting the burden on any human being.
Ciao,
Dscho
Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
Quoted 22 lines · Johannes Schindelin
Hi Junio,
Quoted 18 lines · Junio C Hamano
Quoted 15 lines · Johannes Schindelin
Quoted 5 lines
Quoted 5 lines
Hmph, I wonder why this was sent my way. How does GGG determine whom to send patches to? I, like other reviewers, prefer not to see earlier rounds of patches sent directly to me unless they are about areas that I am mostly responsible for (other patches I'll see them and review them on the copies sent to the mailing list anyway).
Oops, I forgot to address this. The reason why this is sent your way is that you are the Git maintainer, and as such, GitGitGadget sends _all_ Git patches your way (except the Git GUI ones).
The reason for this is that this is the suggested way, as per
https://git-scm.com/docs/SubmittingPatches#patch-flow:Quoted 2 lines
5. The list forms consensus that the last round of your patch is good. Send it to the maintainer and cc the list.
Quoted 7 lines
Quoted 3 lines
Yeah, but as far as I can tell, this is the _first_ round the list sees this topic, which by definition would not have any consensus ;-)
I thought about it for over a year and still have no clue how we could teach GitGitGadget to Cc: you when it is appropriate, not without putting the burden on any human being.
That message is from November 2019, didn't you later fix this in January 2020 here: https://github.com/gitgitgadget/gitgitgadget/commit/b2221f4 ?
I.e. now users need to explicitly add "cc: [email protected]" to the description, no? So isn't in the same as for us who use the format-patch/send-email flow in this regard?
Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
Hi Ævar,
Quoted 28 lines · Ævar Arnfjörð Bjarmason
Quoted 26 lines · Johannes Schindelin
Hi Junio,
Quoted 21 lines · Junio C Hamano
Quoted 6 lines · Johannes Schindelin
Quoted 5 lines
Quoted 5 lines
Hmph, I wonder why this was sent my way. How does GGG determine whom to send patches to? I, like other reviewers, prefer not to see earlier rounds of patches sent directly to me unless they are about areas that I am mostly responsible for (other patches I'll see them and review them on the copies sent to the mailing list anyway).
Quoted 9 lines
Oops, I forgot to address this. The reason why this is sent your way is that you are the Git maintainer, and as such, GitGitGadget sends _all_ Git patches your way (except the Git GUI ones).
The reason for this is that this is the suggested way, as per
https://git-scm.com/docs/SubmittingPatches#patch-flow:Quoted 2 lines
5. The list forms consensus that the last round of your patch is good. Send it to the maintainer and cc the list.
Yeah, but as far as I can tell, this is the _first_ round the list sees this topic, which by definition would not have any consensus ;-)
Quoted 6 lines
Quoted 3 lines
I thought about it for over a year and still have no clue how we could teach GitGitGadget to Cc: you when it is appropriate, not without putting the burden on any human being.
That message is from November 2019, didn't you later fix this in January 2020 here: https://github.com/gitgitgadget/gitgitgadget/commit/b2221f4 ?
I would not call that a fix. As mentioned, I could not come up with a way to Cc: Junio only when appropriate in a way that wouldn't surprise new users. So yes, I disabled the auto-Cc:ing, with no appropriate replacement.
Quoted 3 lines
I.e. now users need to explicitly add "cc: [email protected]" to the description, no? So isn't in the same as for us who use the format-patch/send-email flow in this regard?
Right. And that is... intuitive? If you have to read the manual, the design is broken.
Ciao,
Dscho
Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
Quoted 11 lines · Johannes Schindelin
I would not call that a fix. As mentioned, I could not come up with a way to Cc: Junio only when appropriate in a way that wouldn't surprise new users. So yes, I disabled the auto-Cc:ing, with no appropriate replacement.
Quoted 3 lines
I.e. now users need to explicitly add "cc: [email protected]" to the description, no? So isn't in the same as for us who use the format-patch/send-email flow in this regard?
Right. And that is... intuitive? If you have to read the manual, the design is broken.
Let's step back and think when a patch submitter wants to CC anybody. People explicitly Cc area experts when touching certain part of the codebase, so that they can ask for their input. People also explicitly Cc the maintainer when they see the reviewers reached a consensus that it is a good idea to apply the patch. These CC has value only because they came from conscious decision by the submitter---they actively asks for help and that nudges the recipient of CC to help them.
Even without such Cc:, stakeholders (both area experts and the maintainer) often notice noteworthy patches and discussions, so between having CC that is thrown around freely without thought and crowds recipient's inbox and not having such thoughtless CC at all, the latter is vastly preferred. The former just diminishes the value of Cc that are added manually by thoughtful people.
In short, "now users need to explicitly add" is a GOOD thing.
The best is to have only thoughtful CC, the second best is not to have automated CC at all, and the worst is always throw automated CC to hurt others who try to make CC mean something by making judicious use of it.
Having said all that.
We may not be able to automate the thinking part to decide when submitter may want to get help, but an automation can help by giving the submitter cues and clues when to ask for help and from whom.
Is there a point in the end-user experience flow, starting at the time when they push their proposed change to their repository, throw a pull request at GitHub, say "/submit", and then GGG finally sends out a patch e-mail, where the GGG machinery can inspect the change and give the user (preferrably before the user says /submit) a hint that says "you may want to add Cc: to these people in such and such case, and if you think the situation falls into these cases, tell me so by saying /submit-with-suggested-cc instead of the usual /submit"?
And "these people" may include those who touched the affected code within the past 6 months, and it may also include the maintainer when the pull request is in its second or later iteration.
Thanks.
Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
Hi Junio,
Quoted 3 lines · Junio C Hamano
We may not be able to automate the thinking part to decide when submitter may want to get help, but an automation can help by giving the submitter cues and clues when to ask for help and from whom.
I fear that we're striking the balance on the side of expecting too much knowledge about project-specific lore from contributors.
My goal with GitGitGadget was to allow competent contributors to focus on addressing their pet peeve with Git, to produce a stellar patch with an outstanding description and get that integrated into the next major Git version, and not have to learn about the culture and mechanics of our patch review process for what may very well be their single contribution to Git.
Just look at the wall of text GitGitGadget first-time users _already_ have to read through, and it does not even catch half of what is relevant for every single contributor:
https://github.com/gitgitgadget/gitgitgadget/blob/HEAD/res/WELCOME.md
Note that this wall of text does not even begin to answer questions such as "how do I know when this patch is accepted?".
The suggestion that the contributor should Cc: you explicitly when the contribution is supposedly ready to advance (according to a set of rules that is not formalized anywhere that I know of) could potentially be added to that wall of text, but I doubt that it will make it easier to contribute even for the most advanced and dedicated software engineers.
Quoted 10 lines
Is there a point in the end-user experience flow, starting at the time when they push their proposed change to their repository, throw a pull request at GitHub, say "/submit", and then GGG finally sends out a patch e-mail, where the GGG machinery can inspect the change and give the user (preferrably before the user says /submit) a hint that says "you may want to add Cc: to these people in such and such case, and if you think the situation falls into these cases, tell me so by saying /submit-with-suggested-cc instead of the usual /submit"?
Quoted 3 lines
And "these people" may include those who touched the affected code within the past 6 months, and it may also include the maintainer when the pull request is in its second or later iteration.
We already have a ticket suggesting to add reviewers:
https://github.com/gitgitgadget/gitgitgadget/issues/219
With this suggestion, too, we could go and extend that wall of text even further and expect contributors to just know what they are supposed to do. But I don't see how that would make this process more inviting to new contributors.
BTW I get the sense that many Git mailing list regulars have this idea that making the review process easier for one-time contributors would invite too many low-quality contributions. However, I see the exact
opposite: professional software engineers I talk to refuse to jump through all those hoops, even if they would be quite capable of producing a stellar patch within no time. At the same time I see a lot of less experienced developers delighting in the struggle^Wchallenge to set up git send-email correctly _just_ to earn bragging rights to have their typo fix in Git's commit history. I am exaggerating here, of course, to make a point. And I think this is a very valid point. We lose contributions (and potential future reviewers) because we make it harder than necessary to contribute to Git.
Ciao,
Dscho
Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
Quoted 2 lines · Johannes Schindelin
But I don't see how that would make this process more inviting to new contributors.
Appearing to be inviting should not be our primary goal.
Instead, the goal should be to make it easier to contribute quality patches. By doing so, the smooth experience may attract more new people, which may end up to be "inviting" in the end, but that is as a side effect.
Quoted 3 lines
BTW I get the sense that many Git mailing list regulars have this idea that making the review process easier for one-time contributors would invite too many low-quality contributions.
I don't get such a sense at all.
Sure, if GGG or any other mechanism encourages spamming the list with low-quality patches, that may harm our productivity, but that is not what we are doing. And I do not see how it can be a source of low-quality contributions to send patches that by default do not CC them to random people when the sender does not know when it is appropriate to do so. Sure, if the patches asked for attention from appropriate reviewers (the maintainer included), it might get more responses, but we more often review patches that are only sent to the list than those that are sent directly to us via Cc _anyway_.
On the other hand, inviting more new people to CC reviewers whose mailboxes are already full when the patches are not yet ready would harm productivity of recipients of such patches.
One attribute of a quality patch is that it is CC'ed to the right people and at the right time.
Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
In reply to Johannes SchindelinQuoted 10 lines · Johannes Schindelin
Hi Junio,
Quoted 3 lines · Junio C Hamano
We may not be able to automate the thinking part to decide when submitter may want to get help, but an automation can help by giving the submitter cues and clues when to ask for help and from whom.
I fear that we're striking the balance on the side of expecting too much knowledge about project-specific lore from contributors.
I think that this could be reasonably addressed. When someone opens a PR (but before the hit /submit), GGG could say:
Your change touches these files, and so suggested reviewers include X, Y, Z. When you believe your submission is in its last round, please also include the maintainer, M.
Quoted 7 lines
We already have a ticket suggesting to add reviewers:
https://github.com/gitgitgadget/gitgitgadget/issues/219With this suggestion, too, we could go and extend that wall of text even further and expect contributors to just know what they are supposed to do. But I don't see how that would make this process more inviting to new contributors.
Yeah, I agree that adding this as a separate step does not make sense, since it's hard to discover such things (especially by individuals who merely want to send a single contribution to the project). Having this happen automatically upon creating a PR would make more sense to me.
Thanks,
Taylor
Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
In reply to Junio C HamanoHi Junio,
Quoted 4 lines · Junio C Hamano
Johannes Schindelin <[email protected]> writes:
One attribute of a quality patch is that it is CC'ed to the right people and at the right time.
That's like saying that a quality guest in my house is one who does not have to ask where the bathroom is.
I want the Git project to be more inviting than that.
Ciao,
Dscho
Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
In reply to Taylor BlauHi Taylor,
Quoted 11 lines · Taylor Blau
Quoted 9 lines · Johannes Schindelin
Quoted 3 lines · Junio C Hamano
We may not be able to automate the thinking part to decide when submitter may want to get help, but an automation can help by giving the submitter cues and clues when to ask for help and from whom.
I fear that we're striking the balance on the side of expecting too much knowledge about project-specific lore from contributors.
Quoted 6 lines
I think that this could be reasonably addressed. When someone opens a PR (but before the hit /submit), GGG could say:
Your change touches these files, and so suggested reviewers include X, Y, Z. When you believe your submission is in its last round, please also include the maintainer, M.
That is an option.
Is it the best option to reach the goal where competent software engineers can focus on improving Git's source code?
Maybe it is not possible do automate what I wish for.
Quoted 8 lines
Quoted 7 lines
We already have a ticket suggesting to add reviewers:
https://github.com/gitgitgadget/gitgitgadget/issues/219With this suggestion, too, we could go and extend that wall of text even further and expect contributors to just know what they are supposed to do. But I don't see how that would make this process more inviting to new contributors.
Quoted 4 lines
Yeah, I agree that adding this as a separate step does not make sense, since it's hard to discover such things (especially by individuals who merely want to send a single contribution to the project). Having this happen automatically upon creating a PR would make more sense to me.
Right.
I always have this contribution in mind: Improve the readability of log --graph output (https://github.com/gitgitgadget/git/pull/383)
This was an excellent contribution. I doubt that we would have received it without GitGitGadget, as the contributor could really focus on the code change instead of the contribution logistics.
We did not exactly make it easy, and I fear that we are losing a lot of potential contributions because of that.
For example, Git is often ridiculed for being hard to use, and I can understand. There has been research into ways to improve that, but little of that research resulted in contributions on the Git mailing list. I would not at all be surprised if that was because of the review process we put up.
Usability is only one area where I think we would benefit from attracting talent. Accessibility is another one. Or UI improvements (consistency, self-explanatory navigation, etc). Or...
Ciao,
Dscho
Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
Quoted 4 lines · Johannes Schindelin
Hi Taylor,
On Fri, 8 Jan 2021, Taylor Blau wrote:
...
Quoted 8 lines
Quoted 6 lines
I think that this could be reasonably addressed. When someone opens a PR (but before the hit /submit), GGG could say:
Your change touches these files, and so suggested reviewers include X, Y, Z. When you believe your submission is in its last round, please also include the maintainer, M.
That is an option.
As Taylor created the above suggestion as a counter-proposal, I can see that I apparently did not express what I meant very well, when I said:
Is there a point in the end-user experience flow, starting at the time when they push their proposed change to their repository, throw a pull request at GitHub, say "/submit", and then GGG finally sends out a patch e-mail, where the GGG machinery can inspect the change and give the user (preferrably before the user says /submit) a hint that says "you may want to add Cc: to these people in such and such case, and if you think the situation falls into these cases, tell me so by saying /submit-with-suggested-cc instead of the usual /submit"?
What Taylor suggested, and what you seem to be agreeing to, is exactly what I had in mind when I wrote the above in my message.
So perhaps we three are on the same page from the beginning ;-)
Looking forward to see a new feature that helps contributors to more easily ask help from appropriate people.
Thanks.
Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
Quoted 13 lines · Junio C Hamano
Quoted 11 lines · Johannes Schindelin
Hi Taylor,
On Fri, 8 Jan 2021, Taylor Blau wrote:
...Quoted 6 lines
I think that this could be reasonably addressed. When someone opens a PR (but before the hit /submit), GGG could say:
Your change touches these files, and so suggested reviewers include X, Y, Z. When you believe your submission is in its last round, please also include the maintainer, M.
Quoted 5 lines
Quoted 1 line
That is an option.
As Taylor created the above suggestion as a counter-proposal, I can see that I apparently did not express what I meant very well, when I said:
...or that I must have not read your email which quite clearly states what I was thinking of, too. ;-).
Quoted 1 line
So perhaps we three are on the same page from the beginning ;-)
I think so.
Thanks,
Taylor
Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
Quoted 8 lines · Taylor Blau
Quoted 3 lines · Junio C Hamano
As Taylor created the above suggestion as a counter-proposal, I can see that I apparently did not express what I meant very well, when I said:
...or that I must have not read your email which quite clearly states what I was thinking of, too. ;-).
Seeing that Dscho had a negative reaction to my rendering of my thought while showing positive one towards yours, I see that what I wrote wasn't clear enough to be understood to at least two people.
Thanks for clearly illustrating a possible end user experience that is desiable.
Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
In reply to Junio C HamanoQuoted 2 lines
Looking forward to see a new feature that helps contributors to more easily ask help from appropriate people.
I'm a novice with lots of interest but lots of problems.
A week ago, I made the following submission:
https://public-inbox.org/git/[email protected]/
https://public-inbox.org/git/0261e5d245ef0a5b9a717be1bc03492d7bc06c5e.1610116600.git.gitgitgadget@gmail.com/
https://public-inbox.org/git/a09a5098aa66ea0ed89fe0fcde3f016b4a65814d.1610116600.git.gitgitgadget@gmail.com/
Now I really want to find the right person to reply to me, but it seems that no one has answered me yet.
Do I have some mistakes in the use of GIT gadgets? Please tell me and I will correct it.
Thanks.
--
ZheNing Hu