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. Some implementations, like AIX, may actually
just provide us a bogus result instead.
It's not worth it for us to come up with heuristics that
guess whether the return value is sensible or not. On good
platforms where gmtime reports the problem to us with NULL,
we will print the epoch value. On bad platforms, we will
print garbage. But our test should be written for the
lowest common denominator so that it passes everywhere.
Reported-by: Charles Bailey <cbaile...@bloomberg.net>
Signed-off-by: Jeff King <p...@peff.net>
---
t/t4212-log-corrupt.sh | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/t/t4212-log-corrupt.sh b/t/t4212-log-corrupt.sh
index 3fa1715..58b792b 100755
--- a/t/t4212-log-corrupt.sh
+++ b/t/t4212-log-corrupt.sh
@@ -82,11 +82,9 @@ test_expect_success 'date parser recognizes time_t overflow'
'
'
# date is within 2^63-1, but enough to choke glibc's gmtime
-test_expect_success 'absurdly far-in-future dates produce sentinel' '
+test_expect_success 'absurdly far-in-future date' '
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
+ git log -1 --format=%ad $commit
'
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
