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