All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: Edwin Fernando <edwinfernando734@gmail.com>, git@vger.kernel.org
Subject: Re: [GSoC] Intro and Micro-project
Date: Tue, 21 Mar 2023 10:41:33 -0700	[thread overview]
Message-ID: <xmqqo7omhuia.fsf@gitster.g> (raw)
In-Reply-To: <ZBnmsoRmQGKkQt+S@nand.local> (Taylor Blau's message of "Tue, 21 Mar 2023 13:17:38 -0400")

Taylor Blau <me@ttaylorr.com> writes:

> That sounds great! I assume that you meant avoiding pipelines where the
> 'git' executable is in a non-terminal position of the pipe, e.g.:
>
>     $ git blah | <something else>
>
> Since if "git blah" exited with a non-zero code or crashed, etc., then
> we wouldn't see the failure since the pipeline would suppress it.
>
> That has been a long-standing goal within the test suite, and I think
> that it's a great project to get you started. It'll ensure that you have
> all of the bits in the right place to get Git running on your machine
> and that you're able to run the tests.

Yes, but can somebody rewrite the micro-project idea page to clarify
what the "pipe" thing is about a bit more, so that you do not have
to repeat the above explanation the next time ;-)?

It is not "we do not want pipe", but it is about "we do not want to
ignore exit status of git".  So just like 

	$ git <subcommand> | <some other command>

sequence is bad, we want to avoid 

	$ <some command> $(git <subcommand>)

that feeds output of Git as an argument to some other command.  And

	<some command> <<EOF
	... some text ...
	$(git <subcommand)
	EOF

is bad too.  But

	var=$(git <subcommand>)

is OK ;-).

  reply	other threads:[~2023-03-21 17:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21 14:38 [GSoC] Intro and Micro-project Edwin Fernando
2023-03-21 15:59 ` Felipe Contreras
2023-03-21 17:17 ` Taylor Blau
2023-03-21 17:41   ` Junio C Hamano [this message]
2023-03-21 18:10     ` Taylor Blau

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=xmqqo7omhuia.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=edwinfernando734@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.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.