All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Amanda Shafack via GitGitGadget <gitgitgadget@gmail.com>,
	Git List <git@vger.kernel.org>,
	Emily Shaffer <emilyshaffer@google.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Amanda Shafack <shafack.likhene@gmail.com>
Subject: Re: [PATCH v2] t9832,t2200: avoid using pipes in git commands
Date: Sun, 18 Oct 2020 13:04:47 -0700	[thread overview]
Message-ID: <xmqqsgab7128.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <CAPig+cR7Hm9m1EiWkr5tKYS3r_zJf98XT7OQ+-Jt4EWkaFQTDw@mail.gmail.com> (Eric Sunshine's message of "Sun, 18 Oct 2020 15:25:40 -0400")

Eric Sunshine <sunshine@sunshineco.com> writes:

> precise, the subject could say:
>
>     t2200,t9832: avoid using `git` upstream in a pipe
>
> Nit: It's subjective, but it feels a bit more natural to list the test
> numbers in ascending order rather than descending order, which is why
> I swapped them around in the example above.

;-)

>> When a git command is upstream in a pipe, an unexpected failure of
>> the git command will go unnoticed.
>>
>> Write out the output of the git command to a file, so as to actively
>> catch a failure of the git command.
>
> It's easy to see from the patch itself that the output of the Git
> command is now written to a file, so it's not necessary to say so in
> the commit message. Therefore, the entire body of the commit message
> could be written more succinctly, perhaps like this:
>
>     Avoid placing `git` upstream in a pipe since doing so throws away
>     its exit code, thus an unexpected failure may go unnoticed.

Yup.

> The actual patch itself looks fine, and these comments about the
> commit message are quite minor, thus there probably is no need to
> re-roll (though feel free to do so if you think the bit of extra
> polishing of the commit message is worthwhile).

IIUC, the microproject experience aims new contributors to get used
to the style of communication that happens during review cycles of a
typical topic, using a trivial dip-the-toes-in-the-water problem as
an example.  I'd rather not to see contributors get into the habit
of leaving loose ends and have somebody else clean after them.

Thanks.


  reply	other threads:[~2020-10-18 20:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-17 16:02 [PATCH 0/2] [Outreachy][Patch v1] t9832,t2200: avoid using pipes in git related commands Amanda  Shafack  via GitGitGadget
2020-10-17 16:02 ` [PATCH 1/2] t9832,t2200: avoid using pipes in git commands Amanda Shafack via GitGitGadget
2020-10-18  6:11   ` Eric Sunshine
2020-10-18 13:57     ` Amanda Shafack
2020-10-17 16:02 ` [PATCH 2/2] t2200: modify code syntax Amanda  Shafack via GitGitGadget
2020-10-18  5:55   ` Eric Sunshine
2020-10-18 13:59     ` Amanda Shafack
2020-10-18 14:42 ` [PATCH v2] t9832,t2200: avoid using pipes in git commands Amanda  Shafack  via GitGitGadget
2020-10-18 19:25   ` Eric Sunshine
2020-10-18 20:04     ` Junio C Hamano [this message]
2020-10-18 22:04       ` Amanda Shafack
2020-10-18 20:40     ` Amanda Shafack
2020-10-18 20:48   ` [PATCH v3] t2200,t9832: avoid using 'git' upstream in a pipe Amanda  Shafack  via GitGitGadget
2020-10-18 21:01     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqsgab7128.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jrnieder@gmail.com \
    --cc=shafack.likhene@gmail.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.