git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	Andreas Schwab <schwab@linux-m68k.org>,
	git@vger.kernel.org
Subject: Re: [ANNOUNCE] Git v2.9.1
Date: Tue, 12 Jul 2016 10:04:28 -0400	[thread overview]
Message-ID: <20160712140427.GB613@sigill.intra.peff.net> (raw)
In-Reply-To: <alpine.DEB.2.20.1607121257450.6426@virtualbox>

On Tue, Jul 12, 2016 at 01:25:20PM +0200, Johannes Schindelin wrote:

> [PATCH] Work around test failures due to timestamps being unsigned long
> 
> Git's source code refers to timestamps as unsigned longs. On 32-bit
> platforms, as well as on Windows, unsigned long is not large enough to
> capture dates that are "absurdly far in the future".
> 
> While we will fix this issue properly by replacing unsigned long ->
> time_t, on the maint track we want to be a bit more conservative and
> just skip those tests.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---

This looks like a reasonable interim fix for both Windows and for the
general maint track. If we reliably produce "2038" for the 999... value
then that's simpler than adding in magic to ask about sizeof(ulong). I
also wondered if we should test forthe _correct_ value, but that would
defeat the point of the test (999... is also far in the future).

One minor comment:

> diff --git a/t/t0006-date.sh b/t/t0006-date.sh
> index 04ce535..d185640 100755
> --- a/t/t0006-date.sh
> +++ b/t/t0006-date.sh
> @@ -48,10 +48,17 @@ check_show default "$TIME" 'Wed Jun 15 16:13:20 2016 +0200'
>  check_show raw "$TIME" '1466000000 +0200'
>  check_show iso-local "$TIME" '2016-06-15 14:13:20 +0000'
>  
> -# arbitrary time absurdly far in the future
> -FUTURE="5758122296 -0400"
> -check_show iso       "$FUTURE" "2152-06-19 18:24:56 -0400"
> -check_show iso-local "$FUTURE" "2152-06-19 22:24:56 +0000"
> +case "$(test-date show:iso 9999999999)" in
> +*2038*)
> +	# on this platform, unsigned long is 32-bit, i.e. not large enough
> +	;;
> +*)
> +	# arbitrary time absurdly far in the future
> +	FUTURE="5758122296 -0400"
> +	check_show iso       "$FUTURE" "2152-06-19 18:24:56 -0400"
> +	check_show iso-local "$FUTURE" "2152-06-19 22:24:56 +0000"
> +	;;
> +esac

It would be nice to wrap this in a prereq, like:

  test_lazy_prereq 64BIT_TIME '
	case "$(test-date show:short 9999999999)" in
	*2038*)
		false
		;;
	*)
		true
		;;
	esac
  '

  ...
  check_show 64BIT_TIME iso       "$FUTURE" "2152-06-19 18:24:56 -0400"
  check_show 64BIT_TIME iso-local "$FUTURE" "2152-06-19 22:24:56 +0000"

The main advantage is that it will number the tests consistently, and
give us a "skipped" message (which can remind us to drop the prereq
later when everything goes 64-bit).

But it also will do the right thing with test-date's output with respect
to "-v" (not that we expect it to produce any output).

You'll need to adjust check_show as I did in my earlier patch.

-Peff

  reply	other threads:[~2016-07-12 14:04 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-11 20:13 [ANNOUNCE] Git v2.9.1 Junio C Hamano
2016-07-11 21:35 ` Andreas Schwab
2016-07-11 23:54   ` Jeff King
2016-07-12  0:40     ` Anders Kaseorg
2016-07-12 14:06       ` Jeff King
2016-07-12  0:56     ` Eric Wong
2016-07-12  1:15       ` Jeff King
2016-07-12  1:59     ` Junio C Hamano
2016-07-12  3:57       ` Jeff King
2016-07-12 15:55         ` Junio C Hamano
2016-07-12  7:30       ` Johannes Schindelin
2016-07-12  7:39         ` Jeff King
2016-07-12 11:25           ` Johannes Schindelin
2016-07-12 14:04             ` Jeff King [this message]
2016-07-13 11:35               ` Johannes Schindelin
2016-07-13 16:03                 ` Junio C Hamano
2016-07-13 19:10                   ` Johannes Schindelin
2016-07-13 19:41                     ` Junio C Hamano
2016-07-14  7:50                       ` Johannes Schindelin
2016-07-12 18:12             ` Junio C Hamano
2016-07-13  1:53               ` Junio C Hamano
2016-07-13  2:01               ` Jeff King
2016-07-13 16:05                 ` Junio C Hamano
2016-07-13 18:52                   ` Johannes Schindelin
2016-07-13 19:07                     ` Junio C Hamano
2016-07-14  7:45                       ` Johannes Schindelin
2016-07-14  8:01                         ` Andreas Schwab
2016-07-14  8:15                         ` Jeff King
2016-07-14 16:06                       ` Johannes Schindelin
2016-07-12  7:40         ` Andreas Schwab
2016-07-12 10:57           ` Johannes Schindelin
2016-07-12 13:00             ` Andreas Schwab
2016-07-12 13:22               ` Johannes Schindelin
2016-07-12 13:31                 ` Andreas Schwab
2016-07-12 13:46                   ` Jeff King
2016-07-12 18:38                     ` Duy Nguyen
2016-07-13 11:29                       ` Johannes Schindelin
2016-07-13 11:25                   ` Johannes Schindelin
2016-07-12 14:34         ` Junio C Hamano
2016-07-12 15:16           ` Jeff King
2016-07-12 15:25             ` Junio C Hamano
2016-07-12 15:35               ` Jeff King
2016-07-12 15:41                 ` Junio C Hamano
2016-07-12 16:09                   ` Jeff King
2016-07-12 16:25                     ` Junio C Hamano
2016-07-13 14:00                       ` Johannes Schindelin
2016-07-13 16:10                         ` Junio C Hamano
2016-07-13 18:53                           ` Johannes Schindelin
2016-07-12 18:15                     ` Andreas Schwab
2016-07-13 20:43       ` Junio C Hamano
2016-07-14  7:38         ` Lars Schneider
2016-07-16  5:50           ` Duy Nguyen
2016-07-14  7:58         ` 32-bit Travis, was " Johannes Schindelin
2016-07-14  9:12           ` Mike Hommey
2016-07-14 10:58             ` Johannes Schindelin
2016-07-15  1:59               ` Mike Hommey

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160712140427.GB613@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=schwab@linux-m68k.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).