Re: [PATCH] am: let command-line options override saved options

From: Paul Tan <pyokagan@gmail.com>
Date: Aug 1, 2015, 00:59 UTC
Message-ID: <CACRoPnQHGtA3BQxLuY4douhBt3=_b5U2ny4uDGfmR=5+La68YQ@mail.gmail.com>
In-Reply-To: <xmqqvbd05n5z.fsf@gitster.dls.corp.google.com>

On Sat, Aug 1, 2015 at 12:04 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 25 quoted lines

> Paul Tan <pyokagan@gmail.com> writes:
>
>> I think I will introduce a format_patch() function that takes a single
>> commit-ish so that we can use tag names to name the patches:
>>
>> # Given a single commit $commit, formats the following patches with
>> # git-format-patch:
>> #
>> # 1. $commit.eml: an email patch with a Message-Id header.
>> # 2. $commit.scissors: like $commit.eml but contains a scissors line at the
>> #    start of the commit message body.
>> format_patch () {
>>     {
>>         echo "Message-Id: <$1@example.com>" &&
>>         git format-patch --stdout -1 "$1" | sed -e '1d'
>>     } >"$1".eml &&
>
> I only said I can "understand" what is going on, though.
>
> It feels a bit unnatural for a test to feed a message that lack the
> "From " header line.  Perhaps
>
>         git format-patch --add-header="Message-Id: ..." --stdout -1
>
> or something?

Ah, okay. I wasn't aware of the --add-header option, but this is definitely better.

Show 8 quoted lines

>> These functions are called before we attempt to apply the patch, so we
>> should probably call append_signoff before then. However, this still
>> means that --no-signoff will have no effect should the patch
>> application fail and we resume, as the signoff would still have
>> already been appended...
>
> Ah, I see.  Let's not worry about this; we cannot change the
> expectation existing hook scripts depends on.

Okay, although this means that with the below change, --[no-]signoff will be the oddball option that does not work when resuming.

Show 14 quoted lines

>> 2. Re-reading Peff's message, I see that he expects the command-line
>> options to affect just the current patch, which makes sense. This
>> patch would need to be extended to call am_load() after we finish
>> processing the current patch when resuming.
>
> Yeah, so the idea is:
>
>  - upon the very first invocation, we parse the command line options
>    and write the states out;
>
>  - subsequent invocation, we read from the states and then override
>    with the command line options, but we do not write the states out
>    to update, so that subsequent invocations will keep reading from
>    the very first one.

... and we also load back the saved options after processing the patch that we resume from, so the command-line options only affect the conflicting patch, which fits in with Peff's idea on "wiggling that _one_ patch".

Show 23 quoted lines

>>>> +test_expect_success '--3way, --no-3way' '
>>>> +     rm -fr .git/rebase-apply &&
>>>> +     git reset --hard &&
>>>> +     git checkout first &&
>>>> +     test_must_fail git am --3way side-first.patch side-second.patch &&
>>>> +     test -n "$(git ls-files -u)" &&
>>>> +     echo will-conflict >file &&
>>>> +     git add file &&
>>>> +     test_must_fail git am --no-3way --continue &&
>>>> +     test -z "$(git ls-files -u)"
>>>> +'
>>>> +
>>
>> ... Although if I implement the above change, I can't implement the
>> test for --3way, as I think the only way to check if --3way/--no-3way
>> successfully overrides the saved options for the current patch only is
>> to run "git am --3way", but that does not work in the test runner as
>> it expects stdin to be a TTY :-/ So I may have to remove this test.
>> This shouldn't be a problem though, as all the tests in this test
>> suite all test the same mechanism.
>
> Sorry, you lost me.  Where does the TTY come into the picture only
> for --3way (but not for other things like --quiet)?

Ah, sorry, I should have provided more context. This is due to the following block of code:

        /*
         * Catch user error to feed us patches when there is a session
         * in progress:
         *
         * 1. mbox path(s) are provided on the command-line.
         * 2. stdin is not a tty: the user is trying to feed us a patch
         *    from standard input. This is somewhat unreliable -- stdin
         *    could be /dev/null for example and the caller did not
         *    intend to feed us a patch but wanted to continue
         *    unattended.
         */
        if (argc || (resume == RESUME_FALSE && !isatty(0)))
            die(_("previous rebase directory %s still exists but mbox given."),
                state.dir);

And it will activate when git-am is run without --continue/--abort/--skip (e.g. "git am --3way") because the test framework sets stdin to /dev/null.

Thanks, Paul