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. 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.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);
quoted hunk
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.
Hi Phillip,
On Sun, 12 Jan 2020, Phillip Wood wrote:
On 12/01/2020 16:12, Phillip Wood wrote:
quoted
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!
quoted hunk
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);
quoted
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.
Hi Dscho
On 12/01/2020 18:41, Johannes Schindelin wrote:
Hi Phillip,
On Sun, 12 Jan 2020, Phillip Wood wrote:
quoted
On 12/01/2020 16:12, Phillip Wood wrote:
quoted
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.
[...]
quoted
--- >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
quoted
res = setenv("GIT_COMMITTER_DATE",
opts->ignore_date ? "" : datebuf.buf, 1);
quoted
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.
Hi Phillip,
On Fri, 17 Jan 2020, Phillip Wood wrote:
On 12/01/2020 18:41, Johannes Schindelin wrote:
quoted
On Sun, 12 Jan 2020, Phillip Wood wrote:
quoted
On 12/01/2020 16:12, Phillip Wood wrote:
quoted
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.
Thanks for confirming.
quoted
[...]
quoted
--- >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.
I look forward to it!
Dscho