Re: Problems with ra/rebase-i-more-options - should we revert it?

> 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.)

> [...]
>> --- >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 == '@')`

> 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.
>>>
>>