From: Elijah Newren <newren@gmail.com>
Date: Wed, 08 Sep 2021 08:00:43 GMT
Subject: Re: [PATCH 1/2] t4151: document a pair of am --abort bugs
Message-ID: <CABPp-BGD9WdeiquX0eiMz2458pDhJpjOXGyUOqoXu52ohZVCsQ@mail.gmail.com>
In-Reply-To: <xmqq8s077doe.fsf@gitster.g>

On Wed, Sep 8, 2021 at 12:02 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> 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.