Re: [PATCH 1/2] t4151: document a pair of am --abort bugs
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 8, 2021, 16:33 UTC
- Message-ID
- <xmqq1r5z58oq.fsf@gitster.g>
- In-Reply-To
- <CABPp-BGD9WdeiquX0eiMz2458pDhJpjOXGyUOqoXu52ohZVCsQ@mail.gmail.com>
Elijah Newren <newren@gmail.com> writes:
Show 27 quoted lines
> 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.
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.