Subject: Re: [PATCH 1/2] t4151: document a pair of am --abort bugs

From: Junio C Hamano <[email-masked]>
Date: Wed, 08 Sep 2021 09:33:09 -0700

Elijah Newren <[email-masked]> writes:

> On Wed, Sep 8, 2021 at 12:02 AM Junio C Hamano <[email-masked]> wrote:
>>
>> "Elijah Newren via GitGitGadget" <[email-masked]> writes:
>>
>> > +test_expect_failure 'git am --abort returns us to a clean state' '
>> > +     git checkout changes &&
>> > +     git format-patch -1 --stdout conflicting >changes.mbox &&
>> > +     test_must_fail git am --3way changes.mbox &&
>> > +
>> > +     # Make a change related to the rest of the am work
>> > +     echo related change >>file-2 &&
>> > +
>> > +     # Abort, and expect the related change to go away too
>> > +     git am --abort &&
>> > +     git status --porcelain -uno >actual &&
>> > +     test_must_be_empty actual
>>
>> This test makes me worried.  It is perfectly normal for "am" to be
>> asked to work in a dirty working tree as long as the index is clean
>> and the working tree files that are involved in the patch are
>> unmodified.
>
> Ah, I think I am just too used to rebase where it refuses to start if
> the working tree isn't clean, assumed the same with am (which I don't
> use that much), and then projected from there.
>
> I'll drop the second test; thanks for the explanation.

Actually, if you test that unrelated dirty files are kept, then the
test is a welcome addition.  "returns us to a 'clean' state" needs a
bit different title, though.

Thanks.