git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: 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: Sun, 12 Jan 2020 19:41:33 +0100 (CET)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2001121936290.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <089637d7-b4b6-f6ba-cce1-29e22ce47521@gmail.com>

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

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

Thank you so much!

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

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

  reply	other threads:[~2020-01-12 18:41 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 [this message]
2020-01-17 14:11     ` Phillip Wood
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=nycvar.QRO.7.76.6.2001121936290.46@tvgsbejvaqbjf.bet \
    --to=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).