From: Paul Tan <pyokagan@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>,
Git List <git@vger.kernel.org>,
Stefan Beller <sbeller@google.com>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] am: let command-line options override saved options
Date: Sat, 1 Aug 2015 08:59:22 +0800 [thread overview]
Message-ID: <CACRoPnQHGtA3BQxLuY4douhBt3=_b5U2ny4uDGfmR=5+La68YQ@mail.gmail.com> (raw)
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:
> 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.
>> 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
next prev parent reply other threads:[~2015-08-01 0:59 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-24 17:48 "git am" and then "git am -3" regression? Junio C Hamano
2015-07-24 18:09 ` Jeff King
2015-07-26 5:03 ` Paul Tan
2015-07-26 5:21 ` Jeff King
2015-07-27 8:09 ` Matthieu Moy
2015-07-27 8:32 ` Jeff King
2015-07-27 14:21 ` Junio C Hamano
2015-07-28 16:43 ` [PATCH] am: let command-line options override saved options Paul Tan
2015-07-28 16:48 ` Junio C Hamano
2015-07-28 17:09 ` Junio C Hamano
2015-07-31 10:58 ` Paul Tan
2015-07-31 16:04 ` Junio C Hamano
2015-08-01 0:59 ` Paul Tan [this message]
2015-08-04 14:05 ` [PATCH v2 0/3] " Paul Tan
2015-08-04 21:12 ` Junio C Hamano
2015-08-04 14:08 ` Paul Tan
2015-08-04 14:08 ` [PATCH v2 1/3] test_terminal: redirect child process' stdin to a pty Paul Tan
2015-08-06 22:15 ` Eric Sunshine
2015-08-12 4:16 ` Paul Tan
2015-08-04 14:08 ` [PATCH v2 2/3] am: let command-line options override saved options Paul Tan
2015-08-04 14:08 ` [PATCH v2 3/3] am: let --signoff override --no-signoff Paul Tan
2015-08-07 9:29 ` Johannes Schindelin
2015-08-12 3:06 ` Paul Tan
2015-08-12 3:07 ` Paul Tan
2015-08-05 15:41 ` [PATCH v2 0/3] am: let command-line options override saved options Junio C Hamano
2015-08-05 17:51 ` Paul Tan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACRoPnQHGtA3BQxLuY4douhBt3=_b5U2ny4uDGfmR=5+La68YQ@mail.gmail.com' \
--to=pyokagan@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
--cc=peff@peff.net \
--cc=remi.lespinet@ensimag.grenoble-inp.fr \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).