Thread (63 messages) 63 messages, 7 authors, 2024-10-07

Re: [PATCH v2] [Outreachy][Patch v1] t3404: avoid losing exit status to pipes

From: Eric Sunshine <hidden>
Date: 2024-10-07 04:19:35

On Sun, Oct 6, 2024 at 8:29 AM shejialuo [off-list ref] wrote:
On Sun, Oct 06, 2024 at 08:06:10AM -0400, Eric Sunshine wrote:
quoted
Your observation about outdated/confusing "[foo]" annotations is
certainly something the submitter should take into consideration for
future submissions, but does not seem worthy of a reroll, IMHO. First,
`git am` will strip those off automatically, so they won't become part
of the permanent project history anyhow when/if Junio picks up the
patch. Second, asking for a reroll for something which does not impact
the correctness of either the patch or the commit message just makes
busy-work for the submitter and wastes reviewer time (which is a
limited resource on this project). Third, the point of a microproject
is to expose the submitter to the workflow of the Git project and to
the review process, and for reviewers to see how the submitter
responds. That goal has already been achieved in this case, and
rerolling for something so minor provides no additional benefit in
that regard.
Thanks for your detailed explanation here. I don't know that "git am"
could strip those off automatically. I thought the maintainer would
delete "[foo]" manually. So, my main intention here is that I want the
submitter to make it more perfect to reduce the overhead of the
maintainer and also pay attention to this for further submissions.
Okay, that makes sense. Fortunately, the behavior of git-am means that
we don't have to worry about that particular issue.
And from my perspective, the reroll would not bring much overhead for
the submitter, so I expressed my words in the previous email. I know you
concerned that my words would frustrate the Usman.
It's true that I try to be careful to avoid asking submitters to do
unnecessary work, but my bigger concern is that there are many patches
being submitted but very few people reviewing them, so it is a good
idea to avoid piling more work on reviewers if possible.

By the way, I appreciate that you are helping to review patches on
this list; not just this series, but also larger and more complicated
series such as the one for making git-worktree employ relative paths.
And I wanna say this
is not my intention here. I think Usamn has already done a great job for
this microproject to understand the workflow of the Git project. So,
actually we are on the same boat here.
Agreed.
Let me withdraw my previous words ("We should reroll the patch"). This
patch is good and don't need a reroll.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help