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

[Phillip Wood <phillip.wood123@gmail.com>]

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.

Doh I forgot to add --committer-date-is-author-date to the rebase
command line in that test. It passes with that added - how
embarrassing. However it does appear that it prefixes the date in
GIT_COMMITTER_DATE with @@ rather than @. I think (though am not
completely certain yet) the reason the test still passes is that
the date has more than 8 digits so although
match_object_header_date() fails because of the '@@'
match_digit() succeeds once the loop in parse_date_basic() strips
that prefix. Jonathan's test date only has 7 digits so
match_digit() does not treat it as a number of seconds since the
start of the epoch and fails to parse it. The fix for the @@ is
quite simple, the date we read from the author script already has
an @ so we don't need to add another. The diff below shows a 
basic fix but we should get rid of datebuf altogether as we don't 
need it. I need a break now I'll try and put a patch together 
later in the week if no one else has by then.

Best Wishes

Phillip

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