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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 6, 2024 at 8:29 AM shejialuo <shejialuo@xxxxxxxxx> wrote:
> On Sun, Oct 06, 2024 at 08:06:10AM -0400, Eric Sunshine wrote:
> > 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.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux