On Sat, Aug 1, 2015 at 12:04 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Paul Tan <pyokagan@xxxxxxxxx> 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@xxxxxxxxxxx>" &&
>> 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.
>> 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.
>> 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".
>>>> +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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html