From: Junio C Hamano <gitster@pobox.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Tian Yuchen <a3205153416@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH v2] t/perf/p3400: speed up setup using fast-import
Date: Fri, 30 Jan 2026 08:27:14 -0800 [thread overview]
Message-ID: <xmqqcy2r83rx.fsf@gitster.g> (raw)
In-Reply-To: <04005f67-3ec5-4fa7-9fd7-37ef9034286a@kdbg.org> (Johannes Sixt's message of "Fri, 30 Jan 2026 07:41:34 +0100")
Johannes Sixt <j6t@kdbg.org> writes:
> Am 28.01.26 um 17:07 schrieb Tian Yuchen:
>> + test_seq 1000 >content_fwd &&
>> + test_seq 1000 | sort -nr >content_rev &&
>
> Remove another pipe with
>
> sort -nr content_fwd >content_rev &&
I agree with the outcome (i.e., we do not run test_seq twice) but
not necessarily with the motivation (i.e., we do not assume test_seq
may fail and care about its failure code, so no need to avoid pipes
for the sake of avoiding pipes).
>> + (
>> + for i in $(test_seq 100)
>> + do
>> + ...
>> + cat content_rev &&
>> + echo "EOF" || return 1
>
> This is an incorrect use of `return` outside a function. This must be
> `|| exit 1` (or just `|| exit`) to actually break out of the loop.
Good.
> Of course, the error code is ignored, because it is in the upstream of a
> pipe, so in order to fail the complete command, it would be necessary
> that the original error left an incorrect fast-import stream such that
> the down-stream `git fast-import` fails. Otherwise, the entire command
> can complete successfully in an unexpected way.
>
> Maybe instead of a pipe, dump the stream into a temporary file, so that
> the loop's exit code can be captured?
I like this suggestion. A temporary file, unless it is excessively
large, has an additional advantage that it allows you to inspect
after "git fast-import" dies on it.
>> + done
>> + ) | git fast-import &&
> -- Hannes
next prev parent reply other threads:[~2026-01-30 16:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-26 16:56 [PATCH V1][RFC] t/perf/p3400: speed up setup using fast-import Tian Yuchen
2026-01-26 17:06 ` Tian Yuchen
2026-01-28 4:33 ` Tian Yuchen
2026-01-28 15:25 ` Tian Yuchen
2026-01-28 16:07 ` [PATCH v2] " Tian Yuchen
2026-01-30 6:41 ` Johannes Sixt
2026-01-30 9:55 ` Johannes Sixt
2026-01-30 16:27 ` Junio C Hamano [this message]
[not found] ` <b6f12614-ecc1-4d37-ac4c-070925054f28@gmail.com>
2026-01-30 16:47 ` Johannes Sixt
2026-01-30 14:31 ` Phillip Wood
2026-01-30 15:40 ` Tian Yuchen
2026-01-30 16:29 ` [PATCH v3] " Tian Yuchen
2026-01-30 17:01 ` [PATCH v4] " Tian Yuchen
2026-01-30 17:10 ` [PATCH v3] " 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=xmqqcy2r83rx.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=a3205153416@gmail.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox