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