From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Christoph Anton Mitterer <calestyo@scientia.net>
Subject: Re: [PATCH] sequencer: preserve commit messages
Date: Tue, 24 Feb 2015 16:29:01 +0100 [thread overview]
Message-ID: <54EC98BD.7060100@drmicha.warpmail.net> (raw)
In-Reply-To: <xmqqsidwtq4i.fsf@gitster.dls.corp.google.com>
Junio C Hamano venit, vidit, dixit 23.02.2015 19:54:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> sequencer calls "commit" with default options, which implies
>> "--cleanup=default" unless the user specified something else in their
>> config. This leads to cherry-picked commits getting a cleaned up commit
>> message, which is usually not an intended side-effect.
>>
>> Make the sequencer use "--cleanup=verbatim" so that it preserves commit
>> messages independent of the defaults and user config for "commit".
>
> Hmm, wouldn't it introduce a grave regression for users who
> explicitly ask to clean crufty messages up (by setting their own
> commit.cleanup configuration) if you unconditionally force
> "--cleanup=verbatim" here?
>
That's what I meant by possible side-effects below.
There are no side-effects which our tests would catch.
I don't know sequencer.c well enough to know whether run_git_commit()
would be run with a user-edited commit message at all. My (possibly
wrong) understanding is that it is called only when a cherry-pick
succeeds without any conflicts, so that it is called with a commit
message from a pre-existing commit, i.e. a message after cleanup which
is to be preserved as is.
In case of a conflict, resolution is left to be done by the user. But I
guess I'm overlooking --edit and --continue here.
But git cherry-pick without conflict should no re-cleanup the commit
message either, should it?
>> Reported-by: Christoph Anton Mitterer <calestyo@scientia.net>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
>>
>> Notes:
>> All tests run fine with this changed behavior. I don't know
>> whether this may have any side-effects on other (untested)
>> uses of the sequencer.
>>
>> sequencer.c | 1 +
>> t/t3511-cherry-pick-x.sh | 28 ++++++++++++++++++++++++++++
>> 2 files changed, 29 insertions(+)
>>
>> diff --git a/sequencer.c b/sequencer.c
>> index 77a1266..35fe9d9 100644
>> --- a/sequencer.c
>> +++ b/sequencer.c
>> @@ -377,6 +377,7 @@ static int run_git_commit(const char *defmsg, struct replay_opts *opts,
>> argv_array_init(&array);
>> argv_array_push(&array, "commit");
>> argv_array_push(&array, "-n");
>> + argv_array_push(&array, "--cleanup=verbatim");
>
>
>
>>
>> if (opts->gpg_sign)
>> argv_array_pushf(&array, "-S%s", opts->gpg_sign);
>> diff --git a/t/t3511-cherry-pick-x.sh b/t/t3511-cherry-pick-x.sh
>> index f977279..b7dff09 100755
>> --- a/t/t3511-cherry-pick-x.sh
>> +++ b/t/t3511-cherry-pick-x.sh
>> @@ -36,6 +36,20 @@ mesg_with_cherry_footer="$mesg_with_footer_sob
>> (cherry picked from commit da39a3ee5e6b4b0d3255bfef95601890afd80709)
>> Tested-by: C.U. Thor <cuthor@example.com>"
>>
>> +mesg_unclean="$mesg_one_line
>> +
>> +
>> +leading empty lines
>> +
>> +
>> +consecutive empty lines
>> +
>> +# hash tag comment
>> +
>> +trailing empty lines
>> +
>> +
>> +"
>>
>> test_expect_success setup '
>> git config advice.detachedhead false &&
>> @@ -53,6 +67,10 @@ test_expect_success setup '
>> test_commit "$mesg_with_footer_sob" foo b mesg-with-footer-sob &&
>> git reset --hard initial &&
>> test_commit "$mesg_with_cherry_footer" foo b mesg-with-cherry-footer &&
>> + git reset --hard initial &&
>> + test_config commit.cleanup verbatim &&
>> + test_commit "$mesg_unclean" foo b mesg-unclean &&
>> + test_unconfig commit.cleanup &&
>> pristine_detach initial &&
>> test_commit conflicting unrelated
>> '
>> @@ -216,4 +234,14 @@ test_expect_success 'cherry-pick -x -s treats "(cherry picked from..." line as p
>> test_cmp expect actual
>> '
>>
>> +test_expect_success 'cherry-pick preserves commit message' '
>> + pristine_detach initial &&
>> + printf "$mesg_unclean" >expect &&
>> + git log -1 --pretty=format:%B mesg-unclean >actual &&
>> + test_cmp expect actual &&
>> + git cherry-pick mesg-unclean &&
>> + git log -1 --pretty=format:%B >actual &&
>> + test_cmp expect actual
>> +'
>> +
>> test_done
next prev parent reply other threads:[~2015-02-24 15:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-21 17:48 [BUG] git mangles up commit messages on rebase Christoph Anton Mitterer
2015-02-23 13:23 ` [PATCH] sequencer: preserve commit messages Michael J Gruber
2015-02-23 18:54 ` Junio C Hamano
2015-02-24 15:29 ` Michael J Gruber [this message]
2015-02-24 18:29 ` Junio C Hamano
2015-02-25 9:50 ` Michael J Gruber
2015-02-25 18:22 ` Junio C Hamano
2015-02-26 11:05 ` Michael J Gruber
2015-02-26 19:49 ` Junio C Hamano
2015-02-27 15:31 ` Michael J Gruber
2015-02-27 18:31 ` Junio C Hamano
2015-03-06 13:55 ` [PATCHv2] " Michael J Gruber
2015-03-06 18:59 ` Junio C Hamano
2015-02-25 13:44 ` [PATCH] " Christoph Anton Mitterer
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54EC98BD.7060100@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=calestyo@scientia.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.