One of the tests in t4212 checks our behavior when we feed
gmtime a date so far in the future that it gives up and
returns NULL.
But some gmtime implementations just refuse to quit. They
soldier on, giving us a glimpse of a chilly October evening
some 160 million years in the future (and presumably filled
with our leather-clad horseback-riding ape descendants).
Let's allow the test to match either the sentinel value
(i.e., what we want when gmtime gives up) or any reasonable
value returned by known implementations.
Reported-by: Charles Bailey <cbaile...@bloomberg.net>
Signed-off-by: Jeff King <p...@peff.net>
---
On top of jk/commit-dates-parsing-fix (though the test is already in
v1.9.1).
t/t4212-log-corrupt.sh | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/t/t4212-log-corrupt.sh b/t/t4212-log-corrupt.sh
index 85c6df4..08f982c 100755
--- a/t/t4212-log-corrupt.sh
+++ b/t/t4212-log-corrupt.sh
@@ -76,12 +76,27 @@ test_expect_success 'date parser recognizes time_t
overflow' '
test_cmp expect actual
'
-# date is within 2^63-1, but enough to choke glibc's gmtime
-test_expect_success 'absurdly far-in-future dates produce sentinel' '
+cmp_one_of () {
+ for candidate in "$@"; do
+ echo "$candidate" >expect &&
+ test_cmp expect actual &&
+ return 0
+ done
+ return 1
+}
+
+# date is within 2^63-1, but enough to choke glibc's gmtime.
+# We check that either the date broke gmtime (and we return the
+# usual epoch value), or gmtime gave us some sensible value.
+#
+# The sensible values are determined experimentally. The first
+# is from AIX.
+test_expect_success 'absurdly far-in-future dates' '
commit=$(munge_author_date HEAD 999999999999999999) &&
- echo "Thu Jan 1 00:00:00 1970 +0000" >expect &&
git log -1 --format=%ad $commit >actual &&
- test_cmp expect actual
+ cmp_one_of \
+ "Thu Jan 1 00:00:00 1970 +0000" \
+ "Thu Oct 24 18:46:39 162396404 -0700"
'
test_done
--
1.9.1.656.ge8a0637
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
