From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 1/2] replay: fail gracefully when a merge input is unreadable
Date: Thu, 20 Aug 2026 20:37:03 -0700 [thread overview]
Message-ID: <xmqqh5korvog.fsf@gitster.g> (raw)
In-Reply-To: <CABPp-BGFpLi+FEoJOXvT=wBtexXiDmJ9vXQfc5JnBDrUk+zbDA@mail.gmail.com> (Elijah Newren's message of "Thu, 20 Aug 2026 18:44:05 -0700")
Elijah Newren <newren@gmail.com> writes:
>> > + # Ensure replay gracefully handles the missing object
>> > + test_must_fail git replay --onto onto base..side 2>err &&
>> > + test_grep ! "[Ss]egmentation" err &&
>> > + test_grep "Could not read\|collecting merge info failed" err
>>
>> "test_must_fail" means "the tested command must fail voluntarily and
>> in a controlled way", so a segfaulting git-replay invocation would
>> not pass test_must_fail. Hence, there is no need to separately
>> test "test_grep ! '[sS]egmentation'".
>
> Oops, you're right.
>
> You said on 2/2 that I don't need to rebase because you're putting
> together an evil merge. Do you want me to resubmit with this line
> removed (without changing the series' base), or would you rather I
> avoid that to prevent merging work for you?
I can remove that line myself, or you can resubmit on the same base.
The evil-merge machinery uses the usual 3-way merge, so I do not
think removal of that "test_grep !" line would break it either way.
Thanks.
next prev parent reply other threads:[~2026-08-21 3:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 22:34 [PATCH 0/2] Objects treated as missing despite being present, due to race with geometric repacking Elijah Newren via GitGitGadget
2026-08-18 22:34 ` [PATCH 1/2] replay: fail gracefully when a merge input is unreadable Elijah Newren via GitGitGadget
2026-08-19 18:09 ` Junio C Hamano
2026-08-21 1:44 ` Elijah Newren
2026-08-21 3:37 ` Junio C Hamano [this message]
2026-08-18 22:34 ` [PATCH 2/2] packfile: recover when a multi-pack-index names a removed pack Elijah Newren via GitGitGadget
2026-08-19 18:21 ` Junio C Hamano
2026-08-20 7:54 ` Patrick Steinhardt
2026-08-21 1:36 ` Elijah Newren
2026-08-24 4:48 ` Jeff King
2026-08-24 5:13 ` Patrick Steinhardt
2026-08-24 6:55 ` Jeff King
2026-08-24 7:06 ` Jeff King
2026-08-24 7:23 ` Jeff King
2026-08-24 4:55 ` Jeff King
2026-08-24 5:40 ` Patrick Steinhardt
2026-08-24 7:03 ` Jeff King
2026-08-24 14:45 ` Derrick Stolee
2026-08-24 14:46 ` Derrick Stolee
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=xmqqh5korvog.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=newren@gmail.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.