From: Phillip Wood <phillip.wood123@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
phillip.wood@dunelm.org.uk
Cc: Junio C Hamano <gitster@pobox.com>,
Git Mailing List <git@vger.kernel.org>,
Rohit Ashiwal <rohit.ashiwal265@gmail.com>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Problems with ra/rebase-i-more-options - should we revert it?
Date: Fri, 17 Jan 2020 14:11:21 +0000 [thread overview]
Message-ID: <cdada301-b521-78b4-badc-192af2fa3d08@gmail.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2001121936290.46@tvgsbejvaqbjf.bet>
Hi Dscho
On 12/01/2020 18:41, Johannes Schindelin wrote:
> Hi Phillip,
>
> On Sun, 12 Jan 2020, Phillip Wood wrote:
>
>> On 12/01/2020 16:12, Phillip Wood wrote:
>>> I'm concerned that there are some bugs in this series and think
>>> it may be best to revert it before releasing 2.25.0. Jonathan
>>> Nieder posted a bug report on Friday [1] which I think is caused
>>> by this series. While trying to reproduce Jonathan's bug I came
>>> up with the test below which fails, but not in the same way.
>
> Thank you so much for your thoughts and your work on this. For what it's
> worth, I totally agree with your assessment and your suggestion to revert
> those patches _before_ releasing v2.25.0. (I seem to remember vaguely that
> there were repeated requests for better test coverage and that those
> requests went unaddressed, so I would not be surprised if there were more
> unfortunate surprises waiting for us.)
Yes there were more surprises - when we fork `git merge`
--committer-date-is-author-date is broken. That was tested but with a
commit where the author date was the current time so it did not detect
the failure.
> [...]
>> --- >8 ---
>> diff --git a/sequencer.c b/sequencer.c
>> index 763ccbbc45..22a38de47b 100644
>> --- a/sequencer.c
>> +++ b/sequencer.c
>> @@ -988,7 +988,7 @@ static int run_git_commit(struct repository *r,
>> if (!date)
>> return -1;
>>
>> - strbuf_addf(&datebuf, "@%s", date);
>> + strbuf_addf(&datebuf, "%s", date);
>
> I have to admit that I have not analyzed the code before this hunk (it
> would be much easier to increase the context in a non-static reviewing
> environment, e.g. on GitHub, but the mailing list does not allow for
> that), so I do not know just _how_ likely our `date` here is going to
> change or remain prefixed by a `@`. Therefore, this suggestion might be
> totally stupid: `"@%s", date + (*date == '@')`
The date was read from the author-script so I think we should leave it
as is in case the user has edited it and is using a different date
format. Having said that I'm keen to make a bigger change to Rohit's
implementation and just get the author date out of the argv_array
holding the child's environment as this avoids re-reading the
author-script file. It has taken a bit longer than I planned so it'll be
next week before I post the fixes.
Best Wishes
Phillip
> Thanks again,
> Dscho
>
>> res = setenv("GIT_COMMITTER_DATE",
>> opts->ignore_date ? "" : datebuf.buf, 1);
>>
>>> The
>>> test coverage of this series has always been pretty poor and I
>>> think it needs improving for us to have confidence in it. I'm
>>> also concerned that at least one of the
>>> tests ('--committer-date-is-author-date works with rebase -r')
>>> does not detect failures properly in the code below
>>>
>>> while read HASH
>>> do
>>> git show $HASH --pretty="format:%ai" >authortime
>>> git show $HASH --pretty="format:%ci" >committertime
>>> test_cmp authortime committertime
>>> done <rev_list
>>>
>>>
>>> Best Wishes
>>>
>>> Phillip
>>>
>>> [1] https://lore.kernel.org/git/20200110231436.GA24315@google.com/
>>>
>>> --- >8 ---
>>> diff --git a/t/t3433-rebase-options-compatibility.sh b/t/t3433-rebase-options-compatibility.sh
>>> index 5166f158dd..c81e1d7167 100755
>>> --- a/t/t3433-rebase-options-compatibility.sh
>>> +++ b/t/t3433-rebase-options-compatibility.sh
>>> @@ -6,6 +6,7 @@
>>> test_description='tests to ensure compatibility between am and interactive backends'
>>>
>>> . ./test-lib.sh
>>> +. "$TEST_DIRECTORY"/lib-rebase.sh
>>>
>>> GIT_AUTHOR_DATE="1999-04-02T08:03:20+05:30"
>>> export GIT_AUTHOR_DATE
>>> @@ -99,6 +100,22 @@ test_expect_success '--committer-date-is-author-date works with rebase -r' '
>>> done <rev_list
>>> '
>>>
>>> +test_expect_success '--committer-date-is-author-date works when committing conflict resolution' '
>>> + git checkout commit2 &&
>>> + (
>>> + set_fake_editor &&
>>> + FAKE_LINES=2 &&
>>> + export FAKE_LINES &&
>>> + test_must_fail git rebase -i HEAD^^
>>> + ) &&
>>> + echo resolved > foo &&
>>> + git add foo &&
>>> + git rebase --continue &&
>>> + git log -1 --format=%at commit2 >expect &&
>>> + git log -1 --format=%ct HEAD >actual &&
>>> + test_cmp expect actual
>>> +'
>>> +
>>> # Checking for +0000 in author time is enough since default
>>> # timezone is UTC, but the timezone used while committing
>>> # sets to +0530.
>>>
>>
next prev parent reply other threads:[~2020-01-17 14:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-12 16:12 Problems with ra/rebase-i-more-options - should we revert it? Phillip Wood
2020-01-12 17:31 ` Phillip Wood
2020-01-12 18:41 ` Johannes Schindelin
2020-01-17 14:11 ` Phillip Wood [this message]
2020-01-20 11:15 ` Johannes Schindelin
2020-01-12 21:12 ` Junio C Hamano
2020-01-13 0:43 ` Junio C Hamano
2020-01-13 18:11 ` Junio C Hamano
2020-01-13 22:03 ` "rebase -ri" (was Re: Problems with ra/rebase-i-more-options - should we revert it?) Junio C Hamano
2020-01-15 14:03 ` Johannes Schindelin
2020-01-15 18:14 ` Junio C Hamano
2020-01-15 21:23 ` Rebasing evil merges with --rebase-merges Igor Djordjevic
2020-01-16 7:42 ` Sergey Organov
2020-01-15 22:53 ` "rebase -ri" (was Re: Problems with ra/rebase-i-more-options - should we revert it?) 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=cdada301-b521-78b4-badc-192af2fa3d08@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=rohit.ashiwal265@gmail.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 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).