From: Phillip Wood <phillip.wood123@gmail.com>
To: Jeff King <peff@peff.net>,
Phillip Wood via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,
Jonas Kittner <jonas.kittner@ruhr-uni-bochum.de>,
Junio C Hamano <gitster@pobox.com>,
Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH] rebase -i: fix rewording with --committer-date-is-author-date
Date: Wed, 3 Nov 2021 11:23:28 +0000 [thread overview]
Message-ID: <101071b2-0b7d-5ee8-ca81-171e08a1ffdf@gmail.com> (raw)
In-Reply-To: <YYG8aq85UmMMVW4l@coredump.intra.peff.net>
Hi Peff
On 02/11/2021 22:32, Jeff King wrote:
> On Tue, Nov 02, 2021 at 08:10:44PM +0000, Phillip Wood via GitGitGadget wrote:
>
>> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>>
>> baf8ec8d3a (rebase -r: don't write .git/MERGE_MSG when
>> fast-forwarding, 2021-08-20) stopped reading the author script in
>> run_git_commit() when rewording a commit. This is normally safe
>> because "git commit --amend" preserves the authorship. However if the
>> user passes "--committer-date-is-author-date" then we need to read the
>> author date from the author script when rewording. Fix this regression
>> by tightening the check for when it is safe to skip reading the author
>> script.
>
> That description makes sense, and the patch matches. Not being that
> familiar with this area, my biggest question would be: are there are
> other cases that would need the same treatment? And is there a way we
> can make it easier to avoid forgetting such a case in the future?
I don't think there are any other cases (but then I thought that when I
wrote the buggy patch...). The only time we change the authorship is if
the user passes --committer-date-is-author-date or --reset-author-date.
I agree it would be good to have a way to avoid this problem in the
future but I haven't come up with an easy way to do that. One
possibility would be to go back to always reading the author script.
That would mean revisiting the changes to do_merge() in baf8ec8d3a so
that it always writes the author script and .git/MERGE_MSG but removes
them when fast-forwarding (the problem that baf8ec8d3a tried to solve
was a left over .git/MERGE_MSG when do_merge() fast-forwarded) I don't
want to do that in the rc window though.
>> diff --git a/sequencer.c b/sequencer.c
>> index cd2aabf1f76..ea96837cde3 100644
>> --- a/sequencer.c
>> +++ b/sequencer.c
>> @@ -997,7 +997,9 @@ static int run_git_commit(const char *defmsg,
>>
>> cmd.git_cmd = 1;
>>
>> - if (is_rebase_i(opts) && !(!defmsg && (flags & AMEND_MSG)) &&
>> + if (is_rebase_i(opts) &&
>> + ((opts->committer_date_is_author_date && !opts->ignore_date) ||
>> + !(!defmsg && (flags & AMEND_MSG))) &&
>> read_env_script(&cmd.env_array)) {
>> const char *gpg_opt = gpg_sign_opt_quoted(opts);
>
> This conditional is getting pretty complicated. I wonder if a helper
> like:
>
> if (is_rebase_i(opts) && !needs_env_script(...))
>
> might help, but I guess it needs a funky array of inputs (defmsg, flags,
> and opts). So maybe it is just making things worse.
As you say it needs a lot of inputs so I'm not sure how much a function
would help. I did consider changing it to
if (is_rebase_i(opts) &&
((opts->committer_date_is_author_date && !opts->ignore_date) ||
defmsg || !(flags & AMEND_MSG)))
but as we're in the rc phase I decided to leave the existing condition
alone.
>> +test_expect_success '--committer-date-is-author-date works when rewording' '
>> + GIT_AUTHOR_DATE="@1234 +0300" git commit --amend --reset-author &&
>> + (
>> + set_fake_editor &&
>> + FAKE_COMMIT_MESSAGE=edited \
>> + FAKE_LINES="reword 1" \
>> + git rebase -i --committer-date-is-author-date HEAD^
>> + ) &&
>> + test_write_lines edited "" >expect &&
>> + git log --format="%B" -1 >actual &&
>> + test_cmp expect actual &&
>> + test_ctime_is_atime -1
>> +'
>
> This test make sense (I had to look up what "-1" means for
> test_ctime_is_atime; it's passed to git-log to decide which commits to
> look at).
Yeah I had to check what the -1 was for when writing the test, maybe we
should change the helper to add the '-' for us once 2.34.0 is out.
>> +test_expect_success 'reset-author-date with --committer-date-is-author-date works when rewording' '
>> + GIT_AUTHOR_DATE="@1234 +0300" git commit --amend --reset-author &&
>> + (
>> + set_fake_editor &&
>> + FAKE_COMMIT_MESSAGE=edited \
>> + FAKE_LINES="reword 1" \
>> + git rebase -i --committer-date-is-author-date \
>> + --reset-author-date HEAD^
>> + ) &&
>> + test_write_lines edited "" >expect &&
>> + git log --format="%B" -1 >actual &&
>> + test_cmp expect actual &&
>> + test_atime_is_ignored -1
>> +'
>
> And this one I guess is covering the --ignore-date cut-out in the code?
Yes
> I think it would pass even without it, as that is just noting a case
> where we _don't_ need to call read_env_script().
That's right.
> But I don't know if
> there is any user-visible effect of accidentally calling it when we
> don't need to (my impression is that it's just a performance thing).
There should not be any user-visible effects from reading the author
script when --ignore-date is given but we don't need to read it in that
case so I opted not to.
Thanks for your comments, are you happy for this to go in as is or
should I look at simplifying the conditional?
Phillip
> -Peff
>
next prev parent reply other threads:[~2021-11-03 11:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-02 20:10 [PATCH] rebase -i: fix rewording with --committer-date-is-author-date Phillip Wood via GitGitGadget
2021-11-02 21:05 ` Eric Sunshine
2021-11-02 21:29 ` Phillip Wood
2021-11-02 21:30 ` [PATCH v2] " Phillip Wood via GitGitGadget
2021-11-02 22:32 ` [PATCH] " Jeff King
2021-11-03 11:23 ` Phillip Wood [this message]
2021-11-03 11:42 ` Jeff King
2021-11-03 17:44 ` Junio C Hamano
2021-11-04 2:03 ` Jeff King
2021-11-04 6:27 ` Junio C Hamano
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=101071b2-0b7d-5ee8-ca81-171e08a1ffdf@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=jonas.kittner@ruhr-uni-bochum.de \
--cc=peff@peff.net \
--cc=phillip.wood@dunelm.org.uk \
/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 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 NNTP newsgroup(s).