{"thread":{"id":"42823","subject":"[ANNOUNCE] Git v2.9.1","startedAt":"2016-07-11T20:14:13Z","lastAt":"2016-07-16T05:51:15Z","messageCount":56,"participants":["Junio C Hamano","Andreas Schwab","Jeff King","Anders Kaseorg","Eric Wong","Johannes Schindelin","Duy Nguyen","Lars Schneider","Mike Hommey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"291198","messageId":"xmqqbn247x1f.fsf@gitster.mtv.corp.google.com","threadId":"42823","inReplyTo":null,"subject":"[ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-11T20:13:48Z","receivedAt":"2016-07-11T20:14:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The latest maintenance release Git v2.9.1 is now available at the\nusual places. This release includes fixes to two bugs that have\nbeen reported on the list recently, among other changes:\n\n - v2.9.0 changed cloning of submodules in a top-level superproject\n that was cloned shallowly to explicitly ask for the exact commit\n bound at the superproject, which many instances of servers are\n not yet prepared to handle (the feature appeared in a few\n releases ago but the server operators may not have enabled it\n yet).\n\n - \"git bisect\" at the end tries to give something similar to an\n output from \"git show --raw\" for the found culprit, but the step\n was broken due to an internal API change.\n\nThe tarballs are found at:\n\n https://www.kernel.org/pub/software/scm/git/\n\nThe following public repositories all have a copy of the 'v2.9.1'\ntag and the 'maint' branch that the tag points at:\n\n url = https://kernel.googlesource.com/pub/scm/git/git\n url = git://repo.or.cz/alt-git.git\n url = git://git.sourceforge.jp/gitroot/git-core/git.git\n url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core\n url = https://github.com/gitster/git\n\n----------------------------------------------------------------\n\nGit v2.9.1 Release Notes\n========================\n\nFixes since v2.9\n----------------\n\n * When \"git daemon\" is run without --[init-]timeout specified, a\n connection from a client that silently goes offline can hang around\n for a long time, wasting resources. The socket-level KEEPALIVE has\n been enabled to allow the OS to notice such failed connections.\n\n * The commands in `git log` family take %C(auto) in a custom format\n string. This unconditionally turned the color on, ignoring\n --no-color or with --color=auto when the output is not connected to\n a tty; this was corrected to make the format truly behave as\n \"auto\".\n\n * \"git rev-list --count\" whose walk-length is limited with \"-n\"\n option did not work well with the counting optimized to look at the\n bitmap index.\n\n * \"git show -W\" (extend hunks to cover the entire function, delimited\n by lines that match the \"funcname\" pattern) used to show the entire\n file when a change added an entire function at the end of the file,\n which has been fixed.\n\n * The documentation set has been updated so that literal commands,\n configuration variables and environment variables are consistently\n typeset in fixed-width font and bold in manpages.\n\n * \"git svn propset\" subcommand that was added in 2.3 days is\n documented now.\n\n * The documentation tries to consistently spell \"GPG\"; when\n referring to the specific program name, \"gpg\" is used.\n\n * \"git reflog\" stopped upon seeing an entry that denotes a branch\n creation event (aka \"unborn\"), which made it appear as if the\n reflog was truncated.\n\n * The git-prompt scriptlet (in contrib/) was not friendly with those\n who uses \"set -u\", which has been fixed.\n\n * A codepath that used alloca(3) to place an unbounded amount of data\n on the stack has been updated to avoid doing so.\n\n * \"git update-index --add --chmod=+x file\" may be usable as an escape\n hatch, but not a friendly thing to force for people who do need to\n use it regularly. \"git add --chmod=+x file\" can be used instead.\n\n * Build improvements for gnome-keyring (in contrib/)\n\n * \"git status\" used to say \"working directory\" when it meant \"working\n tree\".\n\n * Comments about misbehaving FreeBSD shells have been clarified with\n the version number (9.x and before are broken, newer ones are OK).\n\n * \"git cherry-pick A\" worked on an unborn branch, but \"git\n cherry-pick A..B\" didn't.\n\n * \"git add -i/-p\" learned to honor diff.compactionHeuristic\n experimental knob, so that the user can work on the same hunk split\n as \"git diff\" output.\n\n * \"log --graph --format=\" learned that \"%>|(N)\" specifies the width\n relative to the terminal's left edge, not relative to the area to\n draw text that is to the right of the ancestry-graph section. It\n also now accepts negative N that means the column limit is relative\n to the right border.\n\n * The ownership rule for the piece of memory that hold references to\n be fetched in \"git fetch\" was screwy, which has been cleaned up.\n\n * \"git bisect\" makes an internal call to \"git diff-tree\" when\n bisection finds the culprit, but this call did not initialize the\n data structure to pass to the diff-tree API correctly.\n\n * Formats of the various data (and how to validate them) where we use\n GPG signature have been documented.\n\n * Fix an unintended regression in v2.9 that breaks \"clone --depth\"\n that recurses down to submodules by forcing the submodules to also\n be cloned shallowly, which many server instances that host upstream\n of the submodules are not prepared for.\n\n * Fix unnecessarily waste in the idiomatic use of ': ${VAR=default}'\n to set the default value, without enclosing it in double quotes.\n\n * Some platform-specific code had non-ANSI strict declarations of C\n functions that do not take any parameters, which has been\n corrected.\n\n * The internal code used to show local timezone offset is not\n prepared to handle timestamps beyond year 2100, and gave a\n bogus offset value to the caller. Use a more benign looking\n +0000 instead and let \"git log\" going in such a case, instead\n of aborting.\n\n * One among four invocations of readlink(1) in our test suite has\n been rewritten so that the test can run on systems without the\n command (others are in valgrind test framework and t9802).\n\n * t/perf needs /usr/bin/time with GNU extension; the invocation of it\n is updated to \"gtime\" on Darwin.\n\n * A bug, which caused \"git p4\" while running under verbose mode to\n report paths that are omitted due to branch prefix incorrectly, has\n been fixed; the command said \"Ignoring file outside of prefix\" for\n paths that are _inside_.\n\n * The top level documentation \"git help git\" still pointed at the\n documentation set hosted at now-defunct google-code repository.\n Update it to point to https://git.github.io/htmldocs/git.html\n instead.\n\nAlso contains minor documentation updates and code clean-ups.\n\n----------------------------------------------------------------\n\nChanges since v2.9.0 are as follows:\n\nAlfred Perlstein (1):\n git-svn: document the 'git svn propset' command\n\nAndrew Oakley (1):\n git-p4: correct hasBranchPrefix verbose output\n\nArmin Kunaschik (1):\n t7800: readlink may not be available\n\nCharles Bailey (1):\n t7810: fix duplicated test title\n\nDave Nicolson (1):\n Documentation: GPG capitalization\n\nDavid Turner (1):\n mailmap: use main email address for dturner\n\nEd Maste (1):\n rebase: update comment about FreeBSD /bin/sh\n\nEdward Thomson (2):\n format_commit_message: honor `color=auto` for `%C(auto)`\n add: add --chmod=+x / --chmod=-x options\n\nEric Wong (1):\n daemon: enable SO_KEEPALIVE for all sockets\n\nHeiko Becker (1):\n gnome-keyring: Don't hard-code pkg-config executable\n\nJeff King (9):\n rev-list: \"adjust\" results of \"--count --use-bitmap-index -n\"\n rev-list: disable bitmaps when \"-n\" is used with listing objects\n tree-diff: avoid alloca for large allocations\n fetch: document that pruning happens before fetching\n add--interactive: respect diff.compactionHeuristic\n bisect: always call setup_revisions after init_revisions\n t0006: rename test-date's \"show\" to \"relative\"\n t0006: test various date formats\n local_tzoffset: detect errors from tm_to_time_t\n\nJohannes Schindelin (3):\n mingw: let the build succeed with DEVELOPER=1\n perf: accommodate for MacOSX\n t2300: \"git --exec-path\" is not usable in $PATH on Windows as-is\n\nJonathan Nieder (1):\n doc: git-htmldocs.googlecode.com is no more\n\nJosef Kufner (1):\n pretty: pass graph width to pretty formatting for use in '%>|(N)'\n\nJunio C Hamano (5):\n blame, line-log: do not loop around deref_tag()\n clone: do not let --depth imply --shallow-submodules\n Start preparing for 2.9.1\n More fixes for 2.9.1\n Git 2.9.1\n\nKeith McGuigan (1):\n builtin/fetch.c: don't free remote->name after fetch\n\nLE Manh Cuong (1):\n sh-setup: enclose setting of ${VAR=default} in double-quotes\n\nLars Vogel (1):\n Use \"working tree\" instead of \"working directory\" for git status\n\nMichael J Gruber (5):\n cherry-pick: allow to pick to unborn branches\n Documentation/technical: describe signature formats\n Documentation/technical: signed tag format\n Documentation/technical: signed commit format\n Documentation/technical: signed merge tag format\n\nNguyễn Thái Ngọc Duy (1):\n pretty.c: support |() forms\n\nPeter Colberg (2):\n refs.h: fix misspelt \"occurred\" in a comment\n config.c: fix misspelt \"occurred\" in an error message\n\nPranit Bauva (1):\n strbuf: describe the return value of strbuf_read_file\n\nRamsay Jones (1):\n regex: fix a SIZE_MAX macro redefinition warning\n\nRené Scharfe (9):\n t4051: rewrite, add more tests\n xdiff: factor out match_func_rec()\n xdiff: handle appended chunks better with -W\n xdiff: ignore empty lines before added functions with -W\n xdiff: -W: don't include common trailing empty lines in context\n xdiff: don't trim common tail with -W\n t7810: add test for grep -W and trailing empty context lines\n grep: -W: don't extend context to trailing empty lines\n xdiff: fix merging of appended hunk with -W\n\nSZEDER Gábor (1):\n reflog: continue walking the reflog past root commits\n\nStefan Beller (1):\n t5614: don't use subshells\n\nTom Russello (4):\n doc: clearer rule about formatting literals\n doc: change environment variables format\n doc: more consistency in environment variables format\n doc: change configuration variables format\n\nVille Skyttä (1):\n git-prompt.sh: Don't error on null ${ZSH,BASH}_VERSION, $short_sha\n\n"},{"id":"291215","messageId":"87lh17kgdy.fsf@linux-m68k.org","threadId":"42823","inReplyTo":"xmqqbn247x1f.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2016-07-11T21:35:05Z","receivedAt":"2016-07-11T21:35:16Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Junio C Hamano writes:\n\n> local_tzoffset: detect errors from tm_to_time_t\n\nnot ok 19 - show date (iso:5758122296 -0400)\n# \n# echo \"$time -> $expect\" >expect &&\n# test-date show:$format \"$time\" >actual &&\n# test_cmp expect actual\n# \nnot ok 20 - show date (iso-local:5758122296 -0400)\n# \n# echo \"$time -> $expect\" >expect &&\n# test-date show:$format \"$time\" >actual &&\n# test_cmp expect actual\n\nThis is outside the range of 32bit time_t.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"291225","messageId":"20160711235417.GA26163@sigill.intra.peff.net","threadId":"42823","inReplyTo":"87lh17kgdy.fsf@linux-m68k.org","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-07-11T23:54:18Z","receivedAt":"2016-07-11T23:54:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 11, 2016 at 11:35:05PM +0200, Andreas Schwab wrote:\n\n> Junio C Hamano writes:\n> \n> > local_tzoffset: detect errors from tm_to_time_t\n> \n> not ok 19 - show date (iso:5758122296 -0400)\n> # \n> # echo \"$time -> $expect\" >expect &&\n> # test-date show:$format \"$time\" >actual &&\n> # test_cmp expect actual\n> # \n> not ok 20 - show date (iso-local:5758122296 -0400)\n> # \n> # echo \"$time -> $expect\" >expect &&\n> # test-date show:$format \"$time\" >actual &&\n> # test_cmp expect actual\n> \n> This is outside the range of 32bit time_t.\n\nYes, that's somewhat the point of the test.\n\nHow does it fail for you (what does it look like with \"-v\")? We may be\nable to check for an outcome that matches both cases.\n\nOtherwise, we'll have to skip the test, perhaps with something like the\npatch below. I suspect the problem is actually the size of \"unsigned\nlong\", not time_t, as we use that internally for a bunch of time\ncomputation.\n\n---\ndiff --git a/help.c b/help.c\nindex 19328ea..0cea240 100644\n--- a/help.c\n+++ b/help.c\n@@ -419,6 +419,13 @@ int cmd_version(int argc, const char **argv, const char *prefix)\n \t * with external projects that rely on the output of \"git version\".\n \t */\n \tprintf(\"git version %s\\n\", git_version_string);\n+\twhile (*++argv) {\n+\t\tif (!strcmp(*argv, \"--build-options\")) {\n+\t\t\tprintf(\"sizeof-unsigned-long: %d\",\n+\t\t\t (int)sizeof(unsigned long));\n+\t\t\t/* maybe also save and output GIT-BUILD_OPTIONS? */\n+\t\t}\n+\t}\n \treturn 0;\n }\n \ndiff --git a/t/t0006-date.sh b/t/t0006-date.sh\nindex 04ce535..a0b8497 100755\n--- a/t/t0006-date.sh\n+++ b/t/t0006-date.sh\n@@ -31,7 +31,7 @@ check_show () {\n \tformat=$1\n \ttime=$2\n \texpect=$3\n-\ttest_expect_${4:-success} \"show date ($format:$time)\" '\n+\ttest_expect_success $4 \"show date ($format:$time)\" '\n \t\techo \"$time -> $expect\" >expect &&\n \t\ttest-date show:$format \"$time\" >actual &&\n \t\ttest_cmp expect actual\n@@ -50,8 +50,8 @@ check_show iso-local \"$TIME\" '2016-06-15 14:13:20 +0000'\n \n # arbitrary time absurdly far in the future\n FUTURE=\"5758122296 -0400\"\n-check_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\"\n-check_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\"\n+check_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\" 64BIT\n+check_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\" 64BIT\n \n check_parse() {\n \techo \"$1 -> $2\" >expect\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 0055ebb..d592bdc 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -1111,3 +1111,12 @@ run_with_limited_cmdline () {\n }\n \n test_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'\n+\n+build_option () {\n+\tgit version --build-options |\n+\tsed -ne \"s/^$1: //p\"\n+}\n+\n+test_lazy_prereq 64BIT '\n+\ttest 8 -le \"$(build_option sizeof-unsigned-long)\"\n+'\n"},{"id":"291228","messageId":"57843C98.7020200@mit.edu","threadId":"42823","inReplyTo":"20160711235417.GA26163@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Anders Kaseorg","fromEmail":"andersk@mit.edu","sentAt":"2016-07-12T00:40:56Z","receivedAt":"2016-07-12T00:46:09Z","isPatch":false,"sender":{"key":"andersk@mit.edu","avatar":"https://avatars.githubusercontent.com/u/26471?v=4"},"body":"On 07/11/2016 07:54 PM, Jeff King wrote:\n> Yes, that's somewhat the point of the test.\n>\n> How does it fail for you (what does it look like with \"-v\")? We may be\n> able to check for an outcome that matches both cases.\n\nOn Ubuntu i386 and Ubuntu armhf, I get the following verbose output from \nt0006-date.sh:\n\n\nexpecting success:\n\t\techo \"$time -> $expect\" >expect &&\n\t\ttest-date show:$format \"$time\" >actual &&\n\t\ttest_cmp expect actual\n\t\n--- expect\t2016-07-11 23:20:55.835136188 +0000\n+++ actual\t2016-07-11 23:20:55.835136188 +0000\n@@ -1 +1 @@\n-5758122296 -0400 -> 2152-06-19 18:24:56 -0400\n+5758122296 -0400 -> 2038-01-18 23:14:07 -0400\nnot ok 19 - show date (iso:5758122296 -0400)\n#\t\n#\t\t\techo \"$time -> $expect\" >expect &&\n#\t\t\ttest-date show:$format \"$time\" >actual &&\n#\t\t\ttest_cmp expect actual\n#\t\t\n\nexpecting success:\n\t\techo \"$time -> $expect\" >expect &&\n\t\ttest-date show:$format \"$time\" >actual &&\n\t\ttest_cmp expect actual\n\t\n--- expect\t2016-07-11 23:20:55.839136188 +0000\n+++ actual\t2016-07-11 23:20:55.839136188 +0000\n@@ -1 +1 @@\n-5758122296 -0400 -> 2152-06-19 22:24:56 +0000\n+5758122296 -0400 -> 2038-01-19 03:14:07 +0000\nnot ok 20 - show date (iso-local:5758122296 -0400)\n\n\nAnders\n\n"},{"id":"291229","messageId":"20160712005611.GA16810@dcvr.yhbt.net","threadId":"42823","inReplyTo":"20160711235417.GA26163@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-07-12T00:56:11Z","receivedAt":"2016-07-12T00:56:15Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jeff King wrote:\n> Otherwise, we'll have to skip the test, perhaps with something like the\n> patch below. I suspect the problem is actually the size of \"unsigned\n> long\", not time_t, as we use that internally for a bunch of time\n> computation.\n\nWe should probably be using int64_t for time calculations;\n\"unsigned long\" is 32-bits on 32-bit x86 systems.\n"},{"id":"291231","messageId":"20160712011533.GA28601@sigill.intra.peff.net","threadId":"42823","inReplyTo":"20160712005611.GA16810@dcvr.yhbt.net","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-07-12T01:15:33Z","receivedAt":"2016-07-12T01:15:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 12, 2016 at 12:56:11AM +0000, Eric Wong wrote:\n\n> Jeff King wrote:\n> > Otherwise, we'll have to skip the test, perhaps with something like the\n> > patch below. I suspect the problem is actually the size of \"unsigned\n> > long\", not time_t, as we use that internally for a bunch of time\n> > computation.\n> \n> We should probably be using int64_t for time calculations;\n> \"unsigned long\" is 32-bits on 32-bit x86 systems.\n\nI'd agree (or probably just \"time_t\", which I would hope would be a\nfuture-proof length even on 32-bit systems).\n\nIt's just that it's baked into a lot of different function interfaces\nand structs in the code, and nobody has taken the time to review and\nchange it all (since it doesn't actually affect current timestamps and\nwon't for a while).\n\n-Peff\n"},{"id":"291232","messageId":"xmqqy4577h0o.fsf@gitster.mtv.corp.google.com","threadId":"42823","inReplyTo":"20160711235417.GA26163@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-12T01:59:51Z","receivedAt":"2016-07-12T02:00:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Jul 11, 2016 at 11:35:05PM +0200, Andreas Schwab wrote:\n>\n>> Junio C Hamano writes:\n>> \n>> > local_tzoffset: detect errors from tm_to_time_t\n>> \n>> not ok 19 - show date (iso:5758122296 -0400)\n>> # \n>> # echo \"$time -> $expect\" >expect &&\n>> # test-date show:$format \"$time\" >actual &&\n>> # test_cmp expect actual\n>> # \n>> not ok 20 - show date (iso-local:5758122296 -0400)\n>> # \n>> # echo \"$time -> $expect\" >expect &&\n>> # test-date show:$format \"$time\" >actual &&\n>> # test_cmp expect actual\n>> \n>> This is outside the range of 32bit time_t.\n>\n> Yes, that's somewhat the point of the test.\n>\n> How does it fail for you (what does it look like with \"-v\")? We may be\n> able to check for an outcome that matches both cases.\n>\n> Otherwise, we'll have to skip the test, perhaps with something like the\n> patch below. I suspect the problem is actually the size of \"unsigned\n> long\", not time_t, as we use that internally for a bunch of time\n> computation.\n>\n> ---\n> diff --git a/help.c b/help.c\n> index 19328ea..0cea240 100644\n> --- a/help.c\n> +++ b/help.c\n> @@ -419,6 +419,13 @@ int cmd_version(int argc, const char **argv, const char *prefix)\n> \t * with external projects that rely on the output of \"git version\".\n> \t */\n> \tprintf(\"git version %s\\n\", git_version_string);\n> +\twhile (*++argv) {\n> +\t\tif (!strcmp(*argv, \"--build-options\")) {\n> +\t\t\tprintf(\"sizeof-unsigned-long: %d\",\n> +\t\t\t (int)sizeof(unsigned long));\n> +\t\t\t/* maybe also save and output GIT-BUILD_OPTIONS? */\n> +\t\t}\n> +\t}\n> \treturn 0;\n> }\n\nI had the same thought, except that I would have expected this to go\nto one of these test-* helpers, and then a lazy prereq for 64-bit\ntime_t would be written on top of it to skip these new tests.\n\n> +build_option () {\n> +\tgit version --build-options |\n> +\tsed -ne \"s/^$1: //p\"\n> +}\n> +\n> +test_lazy_prereq 64BIT '\n> +\ttest 8 -le \"$(build_option sizeof-unsigned-long)\"\n> +'\n\nIt is somewhat disturbing that nobody seems to be regularly building\non 32-bit platforms these days, which is the only reason I can think\nof why this was never reported until it hit a maintenance track.\nThis should have been caught last week at f6a729f3 (Merge branch\n'jk/tzoffset-fix', 2016-07-06) when the topic hit 'master' at the\nlatest, and more preferrably it should have already been caught last\nmonth at 08ec8c5e (Merge branch 'jk/tzoffset-fix' into next,\n2016-06-28).\n\nThose who care about 32-bit builds need to start building and\ntesting 'next' and 'master' regularly, or similar breakages are\nbound to continue happening X-<.\n\nVolunteers?\n\nThanks.\n"},{"id":"291236","messageId":"20160712035719.GA30281@sigill.intra.peff.net","threadId":"42823","inReplyTo":"xmqqy4577h0o.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-07-12T03:57:19Z","receivedAt":"2016-07-12T03:57:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 11, 2016 at 06:59:51PM -0700, Junio C Hamano wrote:\n\n> > diff --git a/help.c b/help.c\n> > index 19328ea..0cea240 100644\n> > --- a/help.c\n> > +++ b/help.c\n> > @@ -419,6 +419,13 @@ int cmd_version(int argc, const char **argv, const char *prefix)\n> > \t * with external projects that rely on the output of \"git version\".\n> > \t */\n> > \tprintf(\"git version %s\\n\", git_version_string);\n> > +\twhile (*++argv) {\n> > +\t\tif (!strcmp(*argv, \"--build-options\")) {\n> > +\t\t\tprintf(\"sizeof-unsigned-long: %d\",\n> > +\t\t\t (int)sizeof(unsigned long));\n> > +\t\t\t/* maybe also save and output GIT-BUILD_OPTIONS? */\n> > +\t\t}\n> > +\t}\n> > \treturn 0;\n> > }\n> \n> I had the same thought, except that I would have expected this to go\n> to one of these test-* helpers, and then a lazy prereq for 64-bit\n> time_t would be written on top of it to skip these new tests.\n\nYeah, that would certainly work.\n\nHowever, I was thinking that it might be handy to have this and some\nother information available for helping with debugging. E.g., that we\ncould ask bug reporters for \"git version --build-options\" when we\nsuspect something related to their config.\n\nSomething along the lines of the patch below, which lets you do:\n\n $ ./git version --build-options\n git version 2.9.0.243.g5c589a7.dirty\n sizeof-unsigned-long: 8\n SHELL_PATH: /bin/sh\n PERL_PATH: /usr/bin/perl\n DIFF: diff\n PYTHON_PATH: /usr/bin/python\n TAR: tar\n NO_CURL: \n NO_EXPAT: \n USE_LIBPCRE: YesPlease\n NO_PERL: \n NO_PYTHON: \n NO_UNIX_SOCKETS: \n GIT_TEST_OPTS: --root=/var/ram/git-tests\n NO_GETTEXT: Nope\n GETTEXT_POISON: \n\nThat's not all of the knobs, though; it's just what we stick in\nBUILD-OPTIONS to trigger script rebuilds and communicate with the test\nscripts. So I think there would potentially be further work to do. But\nit's at least a start. I dunno.\n\n> It is somewhat disturbing that nobody seems to be regularly building\n> on 32-bit platforms these days, which is the only reason I can think\n> of why this was never reported until it hit a maintenance track.\n> This should have been caught last week at f6a729f3 (Merge branch\n> 'jk/tzoffset-fix', 2016-07-06) when the topic hit 'master' at the\n> latest, and more preferrably it should have already been caught last\n> month at 08ec8c5e (Merge branch 'jk/tzoffset-fix' into next,\n> 2016-06-28).\n\nI dream of a world where there are no 32-bit platforms at all, but sadly\nwe are stuck in the middle ground where they are rare enough that nobody\nbothers to test on them early, but not rare enough that somebody doesn't\ncomplain within 24 hours of making a release. :-/\n\n-Peff\n\n---\ndiff --git a/Makefile b/Makefile\nindex de5a030..78d96a0 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -669,6 +669,7 @@ XDIFF_LIB = xdiff/lib.a\n VCSSVN_LIB = vcs-svn/lib.a\n \n GENERATED_H += common-cmds.h\n+GENERATED_H += build-options.h\n \n LIB_H = $(shell $(FIND) . \\\n \t-name .git -prune -o \\\n@@ -1711,7 +1712,7 @@ git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)\n \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) git.o \\\n \t\t$(BUILTIN_OBJS) $(LIBS)\n \n-help.sp help.s help.o: common-cmds.h\n+help.sp help.s help.o: common-cmds.h build-options.h\n \n builtin/help.sp builtin/help.s builtin/help.o: common-cmds.h GIT-PREFIX\n builtin/help.sp builtin/help.s builtin/help.o: EXTRA_CPPFLAGS = \\\n@@ -1735,6 +1736,9 @@ common-cmds.h: generate-cmdlist.sh command-list.txt\n common-cmds.h: $(wildcard Documentation/git-*.txt)\n \t$(QUIET_GEN)$(SHELL_PATH) ./generate-cmdlist.sh command-list.txt >$@+ && mv $@+ $@\n \n+build-options.h: generate-build-options.sh GIT-BUILD-OPTIONS\n+\t$(QUIET_GEN)$(SHELL_PATH) ./generate-build-options.sh GIT-BUILD-OPTIONS >$@+ && mv $@+ $@\n+\n SCRIPT_DEFINES = $(SHELL_PATH_SQ):$(DIFF_SQ):$(GIT_VERSION):\\\n \t$(localedir_SQ):$(NO_CURL):$(USE_GETTEXT_SCHEME):$(SANE_TOOL_PATH_SQ):\\\n \t$(gitwebdir_SQ):$(PERL_PATH_SQ):$(SANE_TEXT_GREP)\ndiff --git a/generate-build-options.sh b/generate-build-options.sh\nnew file mode 100644\nindex 0000000..250728f\n--- /dev/null\n+++ b/generate-build-options.sh\n@@ -0,0 +1,25 @@\n+#!/bin/sh\n+\n+c_quote () {\n+\tprintf '%s' \"$1\" |\n+\tsed -e 's/\\\\/\\\\\\\\/g' -e 's/\"/\\\\\"/g'\n+}\n+\n+echo '#ifndef BUILD_OPTIONS_H'\n+echo '#define BUILD_OPTIONS_H'\n+echo \"/* Automatically generated by $0 */\"\n+echo\n+echo '#define BUILD_OPTIONS \\'\n+\n+for source in \"$@\"; do\n+\t# source/eval trickery is there to unquote the values\n+\t. \"./$source\"\n+\tfor var in $(cut -d= -f1 \"$source\"); do\n+\t\tprintf '\"%s: ' \"$var\"\n+\t\teval \"c_quote \\\"\\$$var\\\"\"\n+\t\tprintf '\\\\n\" \\\\\\n'\n+\tdone\n+done\n+\n+echo\n+echo '#endif /* BUILD_OPTIONS_H */'\ndiff --git a/help.c b/help.c\nindex 19328ea..1cbee86 100644\n--- a/help.c\n+++ b/help.c\n@@ -8,6 +8,7 @@\n #include \"column.h\"\n #include \"version.h\"\n #include \"refs.h\"\n+#include \"build-options.h\"\n \n void add_cmdname(struct cmdnames *cmds, const char *name, int len)\n {\n@@ -419,6 +420,13 @@ int cmd_version(int argc, const char **argv, const char *prefix)\n \t * with external projects that rely on the output of \"git version\".\n \t */\n \tprintf(\"git version %s\\n\", git_version_string);\n+\twhile (*++argv) {\n+\t\tif (!strcmp(*argv, \"--build-options\")) {\n+\t\t\tprintf(\"sizeof-unsigned-long: %d\\n\",\n+\t\t\t (int)sizeof(unsigned long));\n+\t\t\tprintf(\"%s\", BUILD_OPTIONS);\n+\t\t}\n+\t}\n \treturn 0;\n }\n \n"},{"id":"291241","messageId":"alpine.DEB.2.20.1607120927410.6426@virtualbox","threadId":"42823","inReplyTo":"xmqqy4577h0o.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-12T07:30:28Z","receivedAt":"2016-07-12T07:30:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio & Peff,\n\nOn Mon, 11 Jul 2016, Junio C Hamano wrote:\n\n> Those who care about 32-bit builds need to start building and\n> testing 'next' and 'master' regularly, or similar breakages are\n> bound to continue happening X-<.\n\nPlease note that \"unsigned long\" is 32-bit even on 64-bit Windows.\n\nFWIW I have this monster patch as a starting point (I plan to work more on\nthis today):\n\n-- snipsnap --\nFrom b65de5a56e18b038d432ba828d7714880b8e285c Mon Sep 17 00:00:00 2001\nFrom: Johannes Schindelin \nDate: Tue, 12 Jul 2016 09:09:07 +0200\nSubject: [PATCH] HOTFIX: use time_t wherever appropriate\n\nGit's source code assumes that unsigned long is at least as precise as\ntime_t. Well, Git's source code is wrong.\n\nSigned-off-by: Johannes Schindelin \n---\n Documentation/technical/api-parse-options.txt | 4 +-\n builtin/fsck.c | 2 +-\n builtin/merge-base.c | 2 +-\n builtin/prune.c | 2 +-\n builtin/reflog.c | 24 +++----\n builtin/show-branch.c | 4 +-\n builtin/worktree.c | 2 +-\n cache.h | 14 ++---\n date.c | 90 +++++++++++++++------------\n parse-options-cb.c | 4 +-\n reflog-walk.c | 8 +--\n refs.c | 14 ++---\n refs.h | 8 +--\n refs/files-backend.c | 4 +-\n revision.c | 6 +-\n sha1_name.c | 6 +-\n t/helper/test-date.c | 2 +-\n t/helper/test-parse-options.c | 4 +-\n vcs-svn/svndump.c | 2 +-\n wt-status.c | 2 +-\n 20 files changed, 106 insertions(+), 98 deletions(-)\n\ndiff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt\nindex 27bd701..6801aad 100644\n--- a/Documentation/technical/api-parse-options.txt\n+++ b/Documentation/technical/api-parse-options.txt\n@@ -178,11 +178,11 @@ There are some macros to easily define options:\n \tscale the provided value by 1024, 1024^2 or 1024^3 respectively.\n \tThe scaled value is put into `unsigned_long_var`.\n \n-`OPT_DATE(short, long, &int_var, description)`::\n+`OPT_DATE(short, long, &time_t_var, description)`::\n \tIntroduce an option with date argument, see `approxidate()`.\n \tThe timestamp is put into `int_var`.\n \n-`OPT_EXPIRY_DATE(short, long, &int_var, description)`::\n+`OPT_EXPIRY_DATE(short, long, &time_t_var, description)`::\n \tIntroduce an option with expiry date argument, see `parse_expiry_date()`.\n \tThe timestamp is put into `int_var`.\n \ndiff --git a/builtin/fsck.c b/builtin/fsck.c\nindex 3f27456..3dfa32b 100644\n--- a/builtin/fsck.c\n+++ b/builtin/fsck.c\n@@ -385,7 +385,7 @@ static void fsck_handle_reflog_sha1(const char *refname, unsigned char *sha1)\n }\n \n static int fsck_handle_reflog_ent(unsigned char *osha1, unsigned char *nsha1,\n-\t\tconst char *email, unsigned long timestamp, int tz,\n+\t\tconst char *email, time_t timestamp, int tz,\n \t\tconst char *message, void *cb_data)\n {\n \tconst char *refname = cb_data;\ndiff --git a/builtin/merge-base.c b/builtin/merge-base.c\nindex c0d1822..85ba332 100644\n--- a/builtin/merge-base.c\n+++ b/builtin/merge-base.c\n@@ -132,7 +132,7 @@ static void add_one_commit(unsigned char *sha1, struct rev_collect *revs)\n }\n \n static int collect_one_reflog_ent(unsigned char *osha1, unsigned char *nsha1,\n-\t\t\t\t const char *ident, unsigned long timestamp,\n+\t\t\t\t const char *ident, time_t timestamp,\n \t\t\t\t int tz, const char *message, void *cbdata)\n {\n \tstruct rev_collect *revs = cbdata;\ndiff --git a/builtin/prune.c b/builtin/prune.c\nindex 8f4f052..5219504 100644\n--- a/builtin/prune.c\n+++ b/builtin/prune.c\n@@ -13,7 +13,7 @@ static const char * const prune_usage[] = {\n };\n static int show_only;\n static int verbose;\n-static unsigned long expire;\n+static time_t expire;\n static int show_progress = -1;\n \n static int prune_tmp_file(const char *fullpath)\ndiff --git a/builtin/reflog.c b/builtin/reflog.c\nindex 7a7136e..331c874 100644\n--- a/builtin/reflog.c\n+++ b/builtin/reflog.c\n@@ -16,14 +16,14 @@ static const char reflog_delete_usage[] =\n static const char reflog_exists_usage[] =\n \"git reflog exists \";\n \n-static unsigned long default_reflog_expire;\n-static unsigned long default_reflog_expire_unreachable;\n+static time_t default_reflog_expire;\n+static time_t default_reflog_expire_unreachable;\n \n struct cmd_reflog_expire_cb {\n \tstruct rev_info revs;\n \tint stalefix;\n-\tunsigned long expire_total;\n-\tunsigned long expire_unreachable;\n+\ttime_t expire_total;\n+\ttime_t expire_unreachable;\n \tint recno;\n };\n \n@@ -219,7 +219,7 @@ static int keep_entry(struct commit **it, unsigned char *sha1)\n static void mark_reachable(struct expire_reflog_policy_cb *cb)\n {\n \tstruct commit_list *pending;\n-\tunsigned long expire_limit = cb->mark_limit;\n+\ttime_t expire_limit = cb->mark_limit;\n \tstruct commit_list *leftover = NULL;\n \n \tfor (pending = cb->mark_list; pending; pending = pending->next)\n@@ -284,7 +284,7 @@ static int unreachable(struct expire_reflog_policy_cb *cb, struct commit *commit\n * Return true iff the specified reflog entry should be expired.\n */\n static int should_expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,\n-\t\t\t\t const char *email, unsigned long timestamp, int tz,\n+\t\t\t\t const char *email, time_t timestamp, int tz,\n \t\t\t\t const char *message, void *cb_data)\n {\n \tstruct expire_reflog_policy_cb *cb = cb_data;\n@@ -392,8 +392,8 @@ static int collect_reflog(const char *ref, const struct object_id *oid, int unus\n \n static struct reflog_expire_cfg {\n \tstruct reflog_expire_cfg *next;\n-\tunsigned long expire_total;\n-\tunsigned long expire_unreachable;\n+\ttime_t expire_total;\n+\ttime_t expire_unreachable;\n \tchar pattern[FLEX_ARRAY];\n } *reflog_expire_cfg, **reflog_expire_cfg_tail;\n \n@@ -415,7 +415,7 @@ static struct reflog_expire_cfg *find_cfg_ent(const char *pattern, size_t len)\n \treturn ent;\n }\n \n-static int parse_expire_cfg_value(const char *var, const char *value, unsigned long *expire)\n+static int parse_expire_cfg_value(const char *var, const char *value, time_t *expire)\n {\n \tif (!value)\n \t\treturn config_error_nonbool(var);\n@@ -433,7 +433,7 @@ static int reflog_expire_config(const char *var, const char *value, void *cb)\n {\n \tconst char *pattern, *key;\n \tint pattern_len;\n-\tunsigned long expire;\n+\ttime_t expire;\n \tint slot;\n \tstruct reflog_expire_cfg *ent;\n \n@@ -515,7 +515,7 @@ static void set_reflog_expiry_param(struct cmd_reflog_expire_cb *cb, int slot, c\n static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)\n {\n \tstruct expire_reflog_policy_cb cb;\n-\tunsigned long now = time(NULL);\n+\ttime_t now = time(NULL);\n \tint i, status, do_all;\n \tint explicit_expiry = 0;\n \tunsigned int flags = 0;\n@@ -616,7 +616,7 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)\n }\n \n static int count_reflog_ent(unsigned char *osha1, unsigned char *nsha1,\n-\t\tconst char *email, unsigned long timestamp, int tz,\n+\t\tconst char *email, time_t timestamp, int tz,\n \t\tconst char *message, void *cb_data)\n {\n \tstruct expire_reflog_policy_cb *cb = cb_data;\ndiff --git a/builtin/show-branch.c b/builtin/show-branch.c\nindex 2566935..56dd9d2 100644\n--- a/builtin/show-branch.c\n+++ b/builtin/show-branch.c\n@@ -742,7 +742,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)\n \t\t\tbase = strtoul(reflog_base, &ep, 10);\n \t\t\tif (*ep) {\n \t\t\t\t/* Ah, that is a date spec... */\n-\t\t\t\tunsigned long at;\n+\t\t\t\ttime_t at;\n \t\t\t\tat = approxidate(reflog_base);\n \t\t\t\tread_ref_at(ref, flags, at, -1, oid.hash, NULL,\n \t\t\t\t\t NULL, NULL, &base);\n@@ -753,7 +753,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)\n \t\t\tchar *logmsg;\n \t\t\tchar *nth_desc;\n \t\t\tconst char *msg;\n-\t\t\tunsigned long timestamp;\n+\t\t\ttime_t timestamp;\n \t\t\tint tz;\n \n \t\t\tif (read_ref_at(ref, flags, 0, base+i, oid.hash, &logmsg,\ndiff --git a/builtin/worktree.c b/builtin/worktree.c\nindex 96a2834..d81857e 100644\n--- a/builtin/worktree.c\n+++ b/builtin/worktree.c\n@@ -28,7 +28,7 @@ struct add_opts {\n \n static int show_only;\n static int verbose;\n-static unsigned long expire;\n+static time_t expire;\n \n static int prune_worktree(const char *id, struct strbuf *reason)\n {\ndiff --git a/cache.h b/cache.h\nindex 1537c00..b972659 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -1241,18 +1241,18 @@ struct date_mode {\n #define DATE_MODE(t) date_mode_from_type(DATE_##t)\n struct date_mode *date_mode_from_type(enum date_mode_type type);\n \n-const char *show_date(unsigned long time, int timezone, const struct date_mode *mode);\n-void show_date_relative(unsigned long time, int tz, const struct timeval *now,\n+const char *show_date(time_t time, int timezone, const struct date_mode *mode);\n+void show_date_relative(time_t time, int tz, const struct timeval *now,\n \t\t\tstruct strbuf *timebuf);\n int parse_date(const char *date, struct strbuf *out);\n-int parse_date_basic(const char *date, unsigned long *timestamp, int *offset);\n-int parse_expiry_date(const char *date, unsigned long *timestamp);\n+int parse_date_basic(const char *date, time_t *timestamp, int *offset);\n+int parse_expiry_date(const char *date, time_t *timestamp);\n void datestamp(struct strbuf *out);\n #define approxidate(s) approxidate_careful((s), NULL)\n-unsigned long approxidate_careful(const char *, int *);\n-unsigned long approxidate_relative(const char *date, const struct timeval *now);\n+time_t approxidate_careful(const char *, int *);\n+time_t approxidate_relative(const char *date, const struct timeval *now);\n void parse_date_format(const char *format, struct date_mode *mode);\n-int date_overflows(unsigned long date);\n+int date_overflows(time_t date);\n \n #define IDENT_STRICT\t 1\n #define IDENT_NO_DATE\t 2\ndiff --git a/date.c b/date.c\nindex 4c7aa9b..7584a78 100644\n--- a/date.c\n+++ b/date.c\n@@ -39,7 +39,7 @@ static const char *weekday_names[] = {\n \t\"Sundays\", \"Mondays\", \"Tuesdays\", \"Wednesdays\", \"Thursdays\", \"Fridays\", \"Saturdays\"\n };\n \n-static time_t gm_time_t(unsigned long time, int tz)\n+static time_t gm_time_t(time_t time, int tz)\n {\n \tint minutes;\n \n@@ -54,7 +54,7 @@ static time_t gm_time_t(unsigned long time, int tz)\n * thing, which means that tz -0100 is passed in as the integer -100,\n * even though it means \"sixty minutes off\"\n */\n-static struct tm *time_to_tm(unsigned long time, int tz)\n+static struct tm *time_to_tm(time_t time, int tz)\n {\n \ttime_t t = gm_time_t(time, tz);\n \treturn gmtime(&t);\n@@ -64,7 +64,7 @@ static struct tm *time_to_tm(unsigned long time, int tz)\n * What value of \"tz\" was in effect back then at \"time\" in the\n * local timezone?\n */\n-static int local_tzoffset(unsigned long time)\n+static int local_tzoffset(time_t time)\n {\n \ttime_t t, t_local;\n \tstruct tm tm;\n@@ -88,11 +88,11 @@ static int local_tzoffset(unsigned long time)\n \treturn offset * eastwest;\n }\n \n-void show_date_relative(unsigned long time, int tz,\n+void show_date_relative(time_t time, int tz,\n \t\t\t const struct timeval *now,\n \t\t\t struct strbuf *timebuf)\n {\n-\tunsigned long diff;\n+\ttime_t diff;\n \tif (now->tv_sec < time) {\n \t\tstrbuf_addstr(timebuf, _(\"in the future\"));\n \t\treturn;\n@@ -100,65 +100,65 @@ void show_date_relative(unsigned long time, int tz,\n \tdiff = now->tv_sec - time;\n \tif (diff < 90) {\n \t\tstrbuf_addf(timebuf,\n-\t\t\t Q_(\"%lu second ago\", \"%lu seconds ago\", diff), diff);\n+\t\t\t Q_(\"%\" PRIuMAX \" second ago\", \"%\" PRIuMAX \" seconds ago\", diff), diff);\n \t\treturn;\n \t}\n \t/* Turn it into minutes */\n \tdiff = (diff + 30) / 60;\n \tif (diff < 90) {\n \t\tstrbuf_addf(timebuf,\n-\t\t\t Q_(\"%lu minute ago\", \"%lu minutes ago\", diff), diff);\n+\t\t\t Q_(\"%\" PRIuMAX \" minute ago\", \"%\" PRIuMAX \" minutes ago\", diff), diff);\n \t\treturn;\n \t}\n \t/* Turn it into hours */\n \tdiff = (diff + 30) / 60;\n \tif (diff < 36) {\n \t\tstrbuf_addf(timebuf,\n-\t\t\t Q_(\"%lu hour ago\", \"%lu hours ago\", diff), diff);\n+\t\t\t Q_(\"%\" PRIuMAX \" hour ago\", \"%\" PRIuMAX \" hours ago\", diff), diff);\n \t\treturn;\n \t}\n \t/* We deal with number of days from here on */\n \tdiff = (diff + 12) / 24;\n \tif (diff < 14) {\n \t\tstrbuf_addf(timebuf,\n-\t\t\t Q_(\"%lu day ago\", \"%lu days ago\", diff), diff);\n+\t\t\t Q_(\"%\" PRIuMAX \" day ago\", \"%\" PRIuMAX \" days ago\", diff), diff);\n \t\treturn;\n \t}\n \t/* Say weeks for the past 10 weeks or so */\n \tif (diff < 70) {\n \t\tstrbuf_addf(timebuf,\n-\t\t\t Q_(\"%lu week ago\", \"%lu weeks ago\", (diff + 3) / 7),\n+\t\t\t Q_(\"%\" PRIuMAX \" week ago\", \"%\" PRIuMAX \" weeks ago\", (diff + 3) / 7),\n \t\t\t (diff + 3) / 7);\n \t\treturn;\n \t}\n \t/* Say months for the past 12 months or so */\n \tif (diff < 365) {\n \t\tstrbuf_addf(timebuf,\n-\t\t\t Q_(\"%lu month ago\", \"%lu months ago\", (diff + 15) / 30),\n+\t\t\t Q_(\"%\" PRIuMAX \" month ago\", \"%\" PRIuMAX \" months ago\", (diff + 15) / 30),\n \t\t\t (diff + 15) / 30);\n \t\treturn;\n \t}\n \t/* Give years and months for 5 years or so */\n \tif (diff < 1825) {\n-\t\tunsigned long totalmonths = (diff * 12 * 2 + 365) / (365 * 2);\n-\t\tunsigned long years = totalmonths / 12;\n-\t\tunsigned long months = totalmonths % 12;\n+\t\ttime_t totalmonths = (diff * 12 * 2 + 365) / (365 * 2);\n+\t\ttime_t years = totalmonths / 12;\n+\t\ttime_t months = totalmonths % 12;\n \t\tif (months) {\n \t\t\tstruct strbuf sb = STRBUF_INIT;\n-\t\t\tstrbuf_addf(&sb, Q_(\"%lu year\", \"%lu years\", years), years);\n+\t\t\tstrbuf_addf(&sb, Q_(\"%\" PRIuMAX \" year\", \"%\" PRIuMAX \" years\", years), years);\n \t\t\tstrbuf_addf(timebuf,\n \t\t\t\t /* TRANSLATORS: \"%s\" is \" years\" */\n-\t\t\t\t Q_(\"%s, %lu month ago\", \"%s, %lu months ago\", months),\n+\t\t\t\t Q_(\"%s, %\" PRIuMAX \" month ago\", \"%s, %\" PRIuMAX \" months ago\", months),\n \t\t\t\t sb.buf, months);\n \t\t\tstrbuf_release(&sb);\n \t\t} else\n \t\t\tstrbuf_addf(timebuf,\n-\t\t\t\t Q_(\"%lu year ago\", \"%lu years ago\", years), years);\n+\t\t\t\t Q_(\"%\" PRIuMAX \" year ago\", \"%\" PRIuMAX \" years ago\", years), years);\n \t\treturn;\n \t}\n \t/* Otherwise, just years. Centuries is probably overkill. */\n \tstrbuf_addf(timebuf,\n-\t\t Q_(\"%lu year ago\", \"%lu years ago\", (diff + 183) / 365),\n+\t\t Q_(\"%\" PRIuMAX \" year ago\", \"%\" PRIuMAX \" years ago\", (diff + 183) / 365),\n \t\t (diff + 183) / 365);\n }\n \n@@ -172,7 +172,7 @@ struct date_mode *date_mode_from_type(enum date_mode_type type)\n \treturn &mode;\n }\n \n-const char *show_date(unsigned long time, int tz, const struct date_mode *mode)\n+const char *show_date(time_t time, int tz, const struct date_mode *mode)\n {\n \tstruct tm *tm;\n \tstatic struct strbuf timebuf = STRBUF_INIT;\n@@ -182,7 +182,7 @@ const char *show_date(unsigned long time, int tz, const struct date_mode *mode)\n \n \tif (mode->type == DATE_RAW) {\n \t\tstrbuf_reset(&timebuf);\n-\t\tstrbuf_addf(&timebuf, \"%lu %+05d\", time, tz);\n+\t\tstrbuf_addf(&timebuf, \"%\" PRIuMAX \" %+05d\", time, tz);\n \t\treturn timebuf.buf;\n \t}\n \n@@ -419,7 +419,7 @@ static int is_date(int year, int month, int day, struct tm *now_tm, time_t now,\n \treturn 0;\n }\n \n-static int match_multi_number(unsigned long num, char c, const char *date,\n+static int match_multi_number(time_t num, char c, const char *date,\n \t\t\t char *end, struct tm *tm, time_t now)\n {\n \tstruct tm now_tm;\n@@ -495,6 +495,12 @@ static inline int nodate(struct tm *tm)\n \t\ttm->tm_sec) < 0;\n }\n \n+#if 0 /* sizeof(time_t) <= sizeof(unsigned long) */\n+#define parse_time_t strtoul\n+#else\n+#define parse_time_t strtoull\n+#endif\n+\n /*\n * We've seen a digit. Time? Year? Date?\n */\n@@ -502,9 +508,9 @@ static int match_digit(const char *date, struct tm *tm, int *offset, int *tm_gmt\n {\n \tint n;\n \tchar *end;\n-\tunsigned long num;\n+\ttime_t num;\n \n-\tnum = strtoul(date, &end, 10);\n+\tnum = parse_time_t(date, &end, 10);\n \n \t/*\n \t * Seconds since 1970? We trigger on that for any numbers with\n@@ -629,7 +635,7 @@ static int match_tz(const char *date, int *offp)\n \treturn end - date;\n }\n \n-static void date_string(unsigned long date, int offset, struct strbuf *buf)\n+static void date_string(time_t date, int offset, struct strbuf *buf)\n {\n \tint sign = '+';\n \n@@ -637,22 +643,22 @@ static void date_string(unsigned long date, int offset, struct strbuf *buf)\n \t\toffset = -offset;\n \t\tsign = '-';\n \t}\n-\tstrbuf_addf(buf, \"%lu %c%02d%02d\", date, sign, offset / 60, offset % 60);\n+\tstrbuf_addf(buf, \"%\" PRIuMAX \" %c%02d%02d\", date, sign, offset / 60, offset % 60);\n }\n \n /*\n * Parse a string like \"0 +0000\" as ancient timestamp near epoch, but\n * only when it appears not as part of any other string.\n */\n-static int match_object_header_date(const char *date, unsigned long *timestamp, int *offset)\n+static int match_object_header_date(const char *date, time_t *timestamp, int *offset)\n {\n \tchar *end;\n-\tunsigned long stamp;\n+\ttime_t stamp;\n \tint ofs;\n \n \tif (*date < '0' || '9' < *date)\n \t\treturn -1;\n-\tstamp = strtoul(date, &end, 10);\n+\tstamp = parse_time_t(date, &end, 10);\n \tif (*end != ' ' || stamp == ULONG_MAX || (end[1] != '+' && end[1] != '-'))\n \t\treturn -1;\n \tdate = end + 2;\n@@ -669,11 +675,11 @@ static int match_object_header_date(const char *date, unsigned long *timestamp,\n \n /* Gr. strptime is crap for this; it doesn't have a way to require RFC2822\n (i.e. English) day/month names, and it doesn't work correctly with %z. */\n-int parse_date_basic(const char *date, unsigned long *timestamp, int *offset)\n+int parse_date_basic(const char *date, time_t *timestamp, int *offset)\n {\n \tstruct tm tm;\n \tint tm_gmt;\n-\tunsigned long dummy_timestamp;\n+\ttime_t dummy_timestamp;\n \tint dummy_offset;\n \n \tif (!timestamp)\n@@ -741,7 +747,7 @@ int parse_date_basic(const char *date, unsigned long *timestamp, int *offset)\n \treturn 0; /* success */\n }\n \n-int parse_expiry_date(const char *date, unsigned long *timestamp)\n+int parse_expiry_date(const char *date, time_t *timestamp)\n {\n \tint errors = 0;\n \n@@ -765,7 +771,7 @@ int parse_expiry_date(const char *date, unsigned long *timestamp)\n \n int parse_date(const char *date, struct strbuf *result)\n {\n-\tunsigned long timestamp;\n+\ttime_t timestamp;\n \tint offset;\n \tif (parse_date_basic(date, ×tamp, &offset))\n \t\treturn -1;\n@@ -837,7 +843,7 @@ void datestamp(struct strbuf *out)\n * Relative time update (eg \"2 days ago\"). If we haven't set the time\n * yet, we need to set it from current time.\n */\n-static unsigned long update_tm(struct tm *tm, struct tm *now, unsigned long sec)\n+static time_t update_tm(struct tm *tm, struct tm *now, time_t sec)\n {\n \ttime_t n;\n \n@@ -1058,7 +1064,7 @@ static const char *approxidate_digit(const char *date, struct tm *tm, int *num,\n \t\t\t\t time_t now)\n {\n \tchar *end;\n-\tunsigned long number = strtoul(date, &end, 10);\n+\ttime_t number = parse_time_t(date, &end, 10);\n \n \tswitch (*end) {\n \tcase ':':\n@@ -1106,7 +1112,7 @@ static void pending_number(struct tm *tm, int *num)\n \t}\n }\n \n-static unsigned long approxidate_str(const char *date,\n+static time_t approxidate_str(const char *date,\n \t\t\t\t const struct timeval *tv,\n \t\t\t\t int *error_ret)\n {\n@@ -1143,9 +1149,9 @@ static unsigned long approxidate_str(const char *date,\n \treturn update_tm(&tm, &now, 0);\n }\n \n-unsigned long approxidate_relative(const char *date, const struct timeval *tv)\n+time_t approxidate_relative(const char *date, const struct timeval *tv)\n {\n-\tunsigned long timestamp;\n+\ttime_t timestamp;\n \tint offset;\n \tint errors = 0;\n \n@@ -1154,10 +1160,10 @@ unsigned long approxidate_relative(const char *date, const struct timeval *tv)\n \treturn approxidate_str(date, tv, &errors);\n }\n \n-unsigned long approxidate_careful(const char *date, int *error_ret)\n+time_t approxidate_careful(const char *date, int *error_ret)\n {\n \tstruct timeval tv;\n-\tunsigned long timestamp;\n+\ttime_t timestamp;\n \tint offset;\n \tint dummy = 0;\n \tif (!error_ret)\n@@ -1172,13 +1178,15 @@ unsigned long approxidate_careful(const char *date, int *error_ret)\n \treturn approxidate_str(date, &tv, error_ret);\n }\n \n-int date_overflows(unsigned long t)\n+int date_overflows(time_t t)\n {\n \ttime_t sys;\n \n-\t/* If we overflowed our unsigned long, that's bad... */\n+#if 0 /* sizeof(time_t) <= sizeof(unsigned long) */\n+\t/* If we overflowed our time_t, that's bad... */\n \tif (t == ULONG_MAX)\n \t\treturn 1;\n+#endif\n \n \t/*\n \t * ...but we also are going to feed the result to system\ndiff --git a/parse-options-cb.c b/parse-options-cb.c\nindex 239898d..9940e68 100644\n--- a/parse-options-cb.c\n+++ b/parse-options-cb.c\n@@ -31,14 +31,14 @@ int parse_opt_abbrev_cb(const struct option *opt, const char *arg, int unset)\n int parse_opt_approxidate_cb(const struct option *opt, const char *arg,\n \t\t\t int unset)\n {\n-\t*(unsigned long *)(opt->value) = approxidate(arg);\n+\t*(time_t *)(opt->value) = approxidate(arg);\n \treturn 0;\n }\n \n int parse_opt_expiry_date_cb(const struct option *opt, const char *arg,\n \t\t\t int unset)\n {\n-\treturn parse_expiry_date(arg, (unsigned long *)opt->value);\n+\treturn parse_expiry_date(arg, (time_t *)opt->value);\n }\n \n int parse_opt_color_flag_cb(const struct option *opt, const char *arg,\ndiff --git a/reflog-walk.c b/reflog-walk.c\nindex a246af2..d1a8673 100644\n--- a/reflog-walk.c\n+++ b/reflog-walk.c\n@@ -12,7 +12,7 @@ struct complete_reflogs {\n \tstruct reflog_info {\n \t\tunsigned char osha1[20], nsha1[20];\n \t\tchar *email;\n-\t\tunsigned long timestamp;\n+\t\ttime_t timestamp;\n \t\tint tz;\n \t\tchar *message;\n \t} *items;\n@@ -20,7 +20,7 @@ struct complete_reflogs {\n };\n \n static int read_one_reflog(unsigned char *osha1, unsigned char *nsha1,\n-\t\tconst char *email, unsigned long timestamp, int tz,\n+\t\tconst char *email, time_t timestamp, int tz,\n \t\tconst char *message, void *cb_data)\n {\n \tstruct complete_reflogs *array = cb_data;\n@@ -69,7 +69,7 @@ static struct complete_reflogs *read_complete_reflog(const char *ref)\n }\n \n static int get_reflog_recno_by_time(struct complete_reflogs *array,\n-\tunsigned long timestamp)\n+\ttime_t timestamp)\n {\n \tint i;\n \tfor (i = array->nr - 1; i >= 0; i--)\n@@ -141,7 +141,7 @@ void init_reflog_walk(struct reflog_walk_info **info)\n int add_reflog_for_walk(struct reflog_walk_info *info,\n \t\tstruct commit *commit, const char *name)\n {\n-\tunsigned long timestamp = 0;\n+\ttime_t timestamp = 0;\n \tint recno = -1;\n \tstruct string_list_item *item;\n \tstruct complete_reflogs *reflogs;\ndiff --git a/refs.c b/refs.c\nindex 87dc82f..ed1970f 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -620,7 +620,7 @@ int is_branch(const char *refname)\n \n struct read_ref_at_cb {\n \tconst char *refname;\n-\tunsigned long at_time;\n+\ttime_t at_time;\n \tint cnt;\n \tint reccnt;\n \tunsigned char *sha1;\n@@ -629,15 +629,15 @@ struct read_ref_at_cb {\n \tunsigned char osha1[20];\n \tunsigned char nsha1[20];\n \tint tz;\n-\tunsigned long date;\n+\ttime_t date;\n \tchar **msg;\n-\tunsigned long *cutoff_time;\n+\ttime_t *cutoff_time;\n \tint *cutoff_tz;\n \tint *cutoff_cnt;\n };\n \n static int read_ref_at_ent(unsigned char *osha1, unsigned char *nsha1,\n-\t\tconst char *email, unsigned long timestamp, int tz,\n+\t\tconst char *email, time_t timestamp, int tz,\n \t\tconst char *message, void *cb_data)\n {\n \tstruct read_ref_at_cb *cb = cb_data;\n@@ -684,7 +684,7 @@ static int read_ref_at_ent(unsigned char *osha1, unsigned char *nsha1,\n }\n \n static int read_ref_at_ent_oldest(unsigned char *osha1, unsigned char *nsha1,\n-\t\t\t\t const char *email, unsigned long timestamp,\n+\t\t\t\t const char *email, time_t timestamp,\n \t\t\t\t int tz, const char *message, void *cb_data)\n {\n \tstruct read_ref_at_cb *cb = cb_data;\n@@ -704,9 +704,9 @@ static int read_ref_at_ent_oldest(unsigned char *osha1, unsigned char *nsha1,\n \treturn 1;\n }\n \n-int read_ref_at(const char *refname, unsigned int flags, unsigned long at_time, int cnt,\n+int read_ref_at(const char *refname, unsigned int flags, time_t at_time, int cnt,\n \t\tunsigned char *sha1, char **msg,\n-\t\tunsigned long *cutoff_time, int *cutoff_tz, int *cutoff_cnt)\n+\t\ttime_t *cutoff_time, int *cutoff_tz, int *cutoff_cnt)\n {\n \tstruct read_ref_at_cb cb;\n \ndiff --git a/refs.h b/refs.h\nindex 56089d5..cac8fbf 100644\n--- a/refs.h\n+++ b/refs.h\n@@ -246,9 +246,9 @@ int safe_create_reflog(const char *refname, int force_create, struct strbuf *err\n \n /** Reads log for the value of ref during at_time. **/\n extern int read_ref_at(const char *refname, unsigned int flags,\n-\t\t unsigned long at_time, int cnt,\n+\t\t time_t at_time, int cnt,\n \t\t unsigned char *sha1, char **msg,\n-\t\t unsigned long *cutoff_time, int *cutoff_tz, int *cutoff_cnt);\n+\t\t time_t *cutoff_time, int *cutoff_tz, int *cutoff_cnt);\n \n /** Check if a particular reflog exists */\n extern int reflog_exists(const char *refname);\n@@ -274,7 +274,7 @@ extern int delete_refs(struct string_list *refnames);\n extern int delete_reflog(const char *refname);\n \n /* iterate over reflog entries */\n-typedef int each_reflog_ent_fn(unsigned char *osha1, unsigned char *nsha1, const char *, unsigned long, int, const char *, void *);\n+typedef int each_reflog_ent_fn(unsigned char *osha1, unsigned char *nsha1, const char *, time_t, int, const char *, void *);\n int for_each_reflog_ent(const char *refname, each_reflog_ent_fn fn, void *cb_data);\n int for_each_reflog_ent_reverse(const char *refname, each_reflog_ent_fn fn, void *cb_data);\n \n@@ -512,7 +512,7 @@ typedef void reflog_expiry_prepare_fn(const char *refname,\n typedef int reflog_expiry_should_prune_fn(unsigned char *osha1,\n \t\t\t\t\t unsigned char *nsha1,\n \t\t\t\t\t const char *email,\n-\t\t\t\t\t unsigned long timestamp, int tz,\n+\t\t\t\t\t time_t timestamp, int tz,\n \t\t\t\t\t const char *message, void *cb_data);\n typedef void reflog_expiry_cleanup_fn(void *cb_data);\n \ndiff --git a/refs/files-backend.c b/refs/files-backend.c\nindex 1f38076..d809c92 100644\n--- a/refs/files-backend.c\n+++ b/refs/files-backend.c\n@@ -2816,7 +2816,7 @@ static int show_one_reflog_ent(struct strbuf *sb, each_reflog_ent_fn fn, void *c\n {\n \tunsigned char osha1[20], nsha1[20];\n \tchar *email_end, *message;\n-\tunsigned long timestamp;\n+\ttime_t timestamp;\n \tint tz;\n \n \t/* old SP new SP name SP time TAB msg LF */\n@@ -3297,7 +3297,7 @@ struct expire_reflog_cb {\n };\n \n static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,\n-\t\t\t const char *email, unsigned long timestamp, int tz,\n+\t\t\t const char *email, time_t timestamp, int tz,\n \t\t\t const char *message, void *cb_data)\n {\n \tstruct expire_reflog_cb *cb = cb_data;\ndiff --git a/revision.c b/revision.c\nindex d30d1c4..7b7b353 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -896,7 +896,7 @@ static void cherry_pick_list(struct commit_list *list, struct rev_info *revs)\n /* How many extra uninteresting commits we want to see.. */\n #define SLOP 5\n \n-static int still_interesting(struct commit_list *src, unsigned long date, int slop,\n+static int still_interesting(struct commit_list *src, time_t date, int slop,\n \t\t\t struct commit **interesting_cache)\n {\n \t/*\n@@ -1030,7 +1030,7 @@ static void limit_left_right(struct commit_list *list, struct rev_info *revs)\n static int limit_list(struct rev_info *revs)\n {\n \tint slop = SLOP;\n-\tunsigned long date = ~0ul;\n+\ttime_t date = ~0ul;\n \tstruct commit_list *list = revs->commits;\n \tstruct commit_list *newlist = NULL;\n \tstruct commit_list **p = &newlist;\n@@ -1227,7 +1227,7 @@ static void handle_one_reflog_commit(unsigned char *sha1, void *cb_data)\n }\n \n static int handle_one_reflog_ent(unsigned char *osha1, unsigned char *nsha1,\n-\t\tconst char *email, unsigned long timestamp, int tz,\n+\t\tconst char *email, time_t timestamp, int tz,\n \t\tconst char *message, void *cb_data)\n {\n \thandle_one_reflog_commit(osha1, cb_data);\ndiff --git a/sha1_name.c b/sha1_name.c\nindex ca7ddd6..7d25734 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -542,8 +542,8 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1,\n \n \tif (reflog_len) {\n \t\tint nth, i;\n-\t\tunsigned long at_time;\n-\t\tunsigned long co_time;\n+\t\ttime_t at_time;\n+\t\ttime_t co_time;\n \t\tint co_tz, co_cnt;\n \n \t\t/* Is it asking for N-th entry, or approxidate? */\n@@ -935,7 +935,7 @@ struct grab_nth_branch_switch_cbdata {\n };\n \n static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,\n-\t\t\t\t const char *email, unsigned long timestamp, int tz,\n+\t\t\t\t const char *email, time_t timestamp, int tz,\n \t\t\t\t const char *message, void *cb_data)\n {\n \tstruct grab_nth_branch_switch_cbdata *cb = cb_data;\ndiff --git a/t/helper/test-date.c b/t/helper/test-date.c\nindex d9ab360..be45d3b 100644\n--- a/t/helper/test-date.c\n+++ b/t/helper/test-date.c\n@@ -32,7 +32,7 @@ static void show_dates(char **argv, const char *format)\n \t\t * Do not use our normal timestamp parsing here, as the point\n \t\t * is to test the formatting code in isolation.\n \t\t */\n-\t\tt = strtol(arg, &arg, 10);\n+\t\tt = strtoull(arg, &arg, 10);\n \t\twhile (*arg == ' ')\n \t\t\targ++;\n \t\ttz = atoi(arg);\ndiff --git a/t/helper/test-parse-options.c b/t/helper/test-parse-options.c\nindex 8a1235d..14cecf4 100644\n--- a/t/helper/test-parse-options.c\n+++ b/t/helper/test-parse-options.c\n@@ -5,7 +5,7 @@\n static int boolean = 0;\n static int integer = 0;\n static unsigned long magnitude = 0;\n-static unsigned long timestamp;\n+static time_t timestamp;\n static int abbrev = 7;\n static int verbose = -1; /* unspecified */\n static int dry_run = 0, quiet = 0;\n@@ -161,7 +161,7 @@ int main(int argc, char **argv)\n \tshow(&expect, &ret, \"boolean: %d\", boolean);\n \tshow(&expect, &ret, \"integer: %d\", integer);\n \tshow(&expect, &ret, \"magnitude: %lu\", magnitude);\n-\tshow(&expect, &ret, \"timestamp: %lu\", timestamp);\n+\tshow(&expect, &ret, \"timestamp: %\" PRIuMAX, timestamp);\n \tshow(&expect, &ret, \"string: %s\", string ? string : \"(not set)\");\n \tshow(&expect, &ret, \"abbrev: %d\", abbrev);\n \tshow(&expect, &ret, \"verbose: %d\", verbose);\ndiff --git a/vcs-svn/svndump.c b/vcs-svn/svndump.c\nindex e4b3959..9e1eb8d 100644\n--- a/vcs-svn/svndump.c\n+++ b/vcs-svn/svndump.c\n@@ -47,7 +47,7 @@ static struct {\n \n static struct {\n \tuint32_t revision;\n-\tunsigned long timestamp;\n+\ttime_t timestamp;\n \tstruct strbuf log, author, note;\n } rev_ctx;\n \ndiff --git a/wt-status.c b/wt-status.c\nindex 4ce4e35..67858ad 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -1303,7 +1303,7 @@ struct grab_1st_switch_cbdata {\n };\n \n static int grab_1st_switch(unsigned char *osha1, unsigned char *nsha1,\n-\t\t\t const char *email, unsigned long timestamp, int tz,\n+\t\t\t const char *email, time_t timestamp, int tz,\n \t\t\t const char *message, void *cb_data)\n {\n \tstruct grab_1st_switch_cbdata *cb = cb_data;\n-- \n2.9.0.278.g1caae67\n\n"},{"id":"291242","messageId":"20160712073912.GA26431@sigill.intra.peff.net","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607120927410.6426@virtualbox","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-07-12T07:39:12Z","receivedAt":"2016-07-12T07:39:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 12, 2016 at 09:30:28AM +0200, Johannes Schindelin wrote:\n\n> On Mon, 11 Jul 2016, Junio C Hamano wrote:\n> \n> > Those who care about 32-bit builds need to start building and\n> > testing 'next' and 'master' regularly, or similar breakages are\n> > bound to continue happening X-<.\n> \n> Please note that \"unsigned long\" is 32-bit even on 64-bit Windows.\n\nYeah, that was part of the reason my run-time test checked\nsizeof(unsigned long), and not any kind of \"are we 64-bit?\" compiler\noptions or output. So the \"64BIT\" prereq is actually a bit of a\nmisnomer; it is really \"is your ULL 64-bit, because that's what we use\nfor time\". :-/\n\n> FWIW I have this monster patch as a starting point (I plan to work more on\n> this today):\n\nCool! Thanks for working on this.\n\nI suspect we should still do something about skipping those tests,\nthough, if only because the v2.9.x maint track is broken, and switching\nto time_t is a sufficiently large change that we probably don't want it\nfor maint (it _seems_ like it shouldn't cause any problems, but I'm\nwondering if we might inadvertently trigger funny issues around\nsignedness or something).\n\n> From b65de5a56e18b038d432ba828d7714880b8e285c Mon Sep 17 00:00:00 2001\n> From: Johannes Schindelin \n> Date: Tue, 12 Jul 2016 09:09:07 +0200\n> Subject: [PATCH] HOTFIX: use time_t wherever appropriate\n> \n> Git's source code assumes that unsigned long is at least as precise as\n> time_t. Well, Git's source code is wrong.\n\nAnother problem with \"unsigned long\" is that we cannot handle times\nolder than 1970. Assuming most systems are sane enough to have a signed\ntime_t these days, this would fix that problem as well.\n\n-Peff\n"},{"id":"291243","messageId":"mvmtwfve22e.fsf@hawking.suse.de","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607120927410.6426@virtualbox","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2016-07-12T07:40:57Z","receivedAt":"2016-07-12T07:41:07Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Johannes Schindelin writes:\n\n> @@ -88,11 +88,11 @@ static int local_tzoffset(unsigned long time)\n> \treturn offset * eastwest;\n> }\n> \n> -void show_date_relative(unsigned long time, int tz,\n> +void show_date_relative(time_t time, int tz,\n> \t\t\t const struct timeval *now,\n> \t\t\t struct strbuf *timebuf)\n> {\n> -\tunsigned long diff;\n> +\ttime_t diff;\n> \tif (now->tv_sec < time) {\n> \t\tstrbuf_addstr(timebuf, _(\"in the future\"));\n> \t\treturn;\n> @@ -100,65 +100,65 @@ void show_date_relative(unsigned long time, int tz,\n> \tdiff = now->tv_sec - time;\n> \tif (diff < 90) {\n> \t\tstrbuf_addf(timebuf,\n> -\t\t\t Q_(\"%lu second ago\", \"%lu seconds ago\", diff), diff);\n> +\t\t\t Q_(\"%\" PRIuMAX \" second ago\", \"%\" PRIuMAX \" seconds ago\", diff), diff);\n\nPRIuMAX isn't compatible with time_t.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"291248","messageId":"alpine.DEB.2.20.1607121257450.6426@virtualbox","threadId":"42823","inReplyTo":"20160712073912.GA26431@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-12T11:25:20Z","receivedAt":"2016-07-12T11:25:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Tue, 12 Jul 2016, Jeff King wrote:\n\n> On Tue, Jul 12, 2016 at 09:30:28AM +0200, Johannes Schindelin wrote:\n> \n> > FWIW I have this monster patch as a starting point (I plan to work more on\n> > this today):\n> \n> Cool! Thanks for working on this.\n\nWell, I had to. Git for Windows v2.9.1 needs to get released, and I won't\ndo that with a failing test suite.\n\n> I suspect we should still do something about skipping those tests,\n> though, if only because the v2.9.x maint track is broken, and switching\n> to time_t is a sufficiently large change that we probably don't want it\n> for maint (it _seems_ like it shouldn't cause any problems, but I'm\n> wondering if we might inadvertently trigger funny issues around\n> signedness or something).\n\nI totally agree that this patch is very, very large. And yeah, this change\nis intrusive enough that it should not hit maint (but then, IMO neither\nshould the change that triggered this test failure have hit maint).\n\nSo I think I'll go with this for the moment (as we all know, my patch\nseries often go through a couple of commenting rounds, and are not always\npicked up quickly, and I do not wait that long with Git for Windows\nv2.9.1):\n\n-- snipsnap --\n[PATCH] Work around test failures due to timestamps being unsigned long\n\nGit's source code refers to timestamps as unsigned longs. On 32-bit\nplatforms, as well as on Windows, unsigned long is not large enough to\ncapture dates that are \"absurdly far in the future\".\n\nWhile we will fix this issue properly by replacing unsigned long ->\ntime_t, on the maint track we want to be a bit more conservative and\njust skip those tests.\n\nSigned-off-by: Johannes Schindelin \n---\n t/t0006-date.sh | 15 +++++++++++----\n 1 file changed, 11 insertions(+), 4 deletions(-)\n\ndiff --git a/t/t0006-date.sh b/t/t0006-date.sh\nindex 04ce535..d185640 100755\n--- a/t/t0006-date.sh\n+++ b/t/t0006-date.sh\n@@ -48,10 +48,17 @@ check_show default \"$TIME\" 'Wed Jun 15 16:13:20 2016 +0200'\n check_show raw \"$TIME\" '1466000000 +0200'\n check_show iso-local \"$TIME\" '2016-06-15 14:13:20 +0000'\n \n-# arbitrary time absurdly far in the future\n-FUTURE=\"5758122296 -0400\"\n-check_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\"\n-check_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\"\n+case \"$(test-date show:iso 9999999999)\" in\n+*2038*)\n+\t# on this platform, unsigned long is 32-bit, i.e. not large enough\n+\t;;\n+*)\n+\t# arbitrary time absurdly far in the future\n+\tFUTURE=\"5758122296 -0400\"\n+\tcheck_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\"\n+\tcheck_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\"\n+\t;;\n+esac\n \n check_parse() {\n \techo \"$1 -> $2\" >expect\n-- \n2.9.0.278.g1caae67\n\n"},{"id":"291249","messageId":"alpine.DEB.2.20.1607121249390.6426@virtualbox","threadId":"42823","inReplyTo":"mvmtwfve22e.fsf@hawking.suse.de","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"schindelin@wisc.edu","sentAt":"2016-07-12T10:57:31Z","receivedAt":"2016-07-12T11:57:54Z","isPatch":false,"sender":{"key":"schindelin@wisc.edu","avatar":null},"body":"Hi Andreas,\n\nOn Tue, 12 Jul 2016, Andreas Schwab wrote:\n\n> Johannes Schindelin writes:\n> \n> > @@ -88,11 +88,11 @@ static int local_tzoffset(unsigned long time)\n> > \treturn offset * eastwest;\n> > }\n> > \n> > -void show_date_relative(unsigned long time, int tz,\n> > +void show_date_relative(time_t time, int tz,\n> > \t\t\t const struct timeval *now,\n> > \t\t\t struct strbuf *timebuf)\n> > {\n> > -\tunsigned long diff;\n> > +\ttime_t diff;\n> > \tif (now->tv_sec < time) {\n> > \t\tstrbuf_addstr(timebuf, _(\"in the future\"));\n> > \t\treturn;\n> > @@ -100,65 +100,65 @@ void show_date_relative(unsigned long time, int tz,\n> > \tdiff = now->tv_sec - time;\n> > \tif (diff < 90) {\n> > \t\tstrbuf_addf(timebuf,\n> > -\t\t\t Q_(\"%lu second ago\", \"%lu seconds ago\", diff), diff);\n> > +\t\t\t Q_(\"%\" PRIuMAX \" second ago\", \"%\" PRIuMAX \" seconds ago\", diff), diff);\n> \n> PRIuMAX isn't compatible with time_t.\n\nThat statement is wrong. But you probably meant that PRIuMAX is *not\nnecessarily* the correct thing to use.\n\nAnd I would agree with that. I had to have a patch that 1) compiles and 2)\nfixes t0006 on Windows, and the patch I presented achieved both goals.\n\nI hoped that my brief \"starting point\" hint would make it obvious that I\ndo not think that this patch is acceptable?\n\nMy idea was to introduce a TIME_T_LARGER_THAN_ULONG and take it from\nthere, but I had to switch contexts before I could finish that part of the\npatch, yet I still wanted to let y'all know that patches are in the\nworking.\n\nFor future record: I appreciate feedback especially when it is\nconstructive, i.e. when \"that's wrong\" is not left on its own, but is\ninstead followed by \"why not do XYZ instead\".\n\nCiao,\nJohannes\n"},{"id":"291250","messageId":"mvmh9bvdnae.fsf@hawking.suse.de","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607121249390.6426@virtualbox","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2016-07-12T13:00:09Z","receivedAt":"2016-07-12T13:00:30Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Johannes Schindelin writes:\n\n>> PRIuMAX isn't compatible with time_t.\n>\n> That statement is wrong.\n\nNo, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t\n(even if they happen to have the same representation).\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"291252","messageId":"alpine.DEB.2.20.1607121520310.6426@virtualbox","threadId":"42823","inReplyTo":"mvmh9bvdnae.fsf@hawking.suse.de","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-12T13:22:08Z","receivedAt":"2016-07-12T13:22:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Andreas,\n\nOn Tue, 12 Jul 2016, Andreas Schwab wrote:\n\n> Johannes Schindelin writes:\n> \n> >> PRIuMAX isn't compatible with time_t.\n> >\n> > That statement is wrong.\n> \n> No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t\n> (even if they happen to have the same representation).\n\nSigh.\n\nSo if it is wrong, what is right? I hoped that my gentle reprimand in my\nprevious reply would result in a more helpful response.\n\nLet me guess: PRId64 is what you would have suggested if you had followed\nup your negative statement with a \"do this instead\"?\n\nCiao,\nJohannes\n"},{"id":"291253","messageId":"mvmd1mjdluz.fsf@hawking.suse.de","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607121520310.6426@virtualbox","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2016-07-12T13:31:00Z","receivedAt":"2016-07-12T13:31:22Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi Andreas,\n>\n> On Tue, 12 Jul 2016, Andreas Schwab wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> >> PRIuMAX isn't compatible with time_t.\n>> >\n>> > That statement is wrong.\n>> \n>> No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t\n>> (even if they happen to have the same representation).\n>\n> Sigh.\n>\n> So if it is wrong, what is right?\n\nThe right thing is to add a cast, of course.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"291255","messageId":"20160712134652.GA613@sigill.intra.peff.net","threadId":"42823","inReplyTo":"mvmd1mjdluz.fsf@hawking.suse.de","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-07-12T13:46:52Z","receivedAt":"2016-07-12T13:47:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote:\n\n> Johannes Schindelin writes:\n> \n> > Hi Andreas,\n> >\n> > On Tue, 12 Jul 2016, Andreas Schwab wrote:\n> >\n> >> Johannes Schindelin writes:\n> >> \n> >> >> PRIuMAX isn't compatible with time_t.\n> >> >\n> >> > That statement is wrong.\n> >> \n> >> No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t\n> >> (even if they happen to have the same representation).\n> >\n> > Sigh.\n> >\n> > So if it is wrong, what is right?\n> \n> The right thing is to add a cast, of course.\n\nIn general, I think the right cast for time_t should be to (intmax_t),\nand the formatting string should be PRIdMAX (which, as an aside, needs\nan entry in git-compat-util.h).\n\nIn this particular code (show_date_relative), though, I think you can\nget away with treating it as unsigned, because it's not actually a\ntime_t but rather a difference. And we handle the negative difference at\nthe top of the function already (\"in the future\").\n\n-Peff\n"},{"id":"291258","messageId":"20160712140427.GB613@sigill.intra.peff.net","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607121257450.6426@virtualbox","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-07-12T14:04:28Z","receivedAt":"2016-07-12T14:04:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 12, 2016 at 01:25:20PM +0200, Johannes Schindelin wrote:\n\n> [PATCH] Work around test failures due to timestamps being unsigned long\n> \n> Git's source code refers to timestamps as unsigned longs. On 32-bit\n> platforms, as well as on Windows, unsigned long is not large enough to\n> capture dates that are \"absurdly far in the future\".\n> \n> While we will fix this issue properly by replacing unsigned long ->\n> time_t, on the maint track we want to be a bit more conservative and\n> just skip those tests.\n> \n> Signed-off-by: Johannes Schindelin \n> ---\n\nThis looks like a reasonable interim fix for both Windows and for the\ngeneral maint track. If we reliably produce \"2038\" for the 999... value\nthen that's simpler than adding in magic to ask about sizeof(ulong). I\nalso wondered if we should test forthe _correct_ value, but that would\ndefeat the point of the test (999... is also far in the future).\n\nOne minor comment:\n\n> diff --git a/t/t0006-date.sh b/t/t0006-date.sh\n> index 04ce535..d185640 100755\n> --- a/t/t0006-date.sh\n> +++ b/t/t0006-date.sh\n> @@ -48,10 +48,17 @@ check_show default \"$TIME\" 'Wed Jun 15 16:13:20 2016 +0200'\n> check_show raw \"$TIME\" '1466000000 +0200'\n> check_show iso-local \"$TIME\" '2016-06-15 14:13:20 +0000'\n> \n> -# arbitrary time absurdly far in the future\n> -FUTURE=\"5758122296 -0400\"\n> -check_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\"\n> -check_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\"\n> +case \"$(test-date show:iso 9999999999)\" in\n> +*2038*)\n> +\t# on this platform, unsigned long is 32-bit, i.e. not large enough\n> +\t;;\n> +*)\n> +\t# arbitrary time absurdly far in the future\n> +\tFUTURE=\"5758122296 -0400\"\n> +\tcheck_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\"\n> +\tcheck_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\"\n> +\t;;\n> +esac\n\nIt would be nice to wrap this in a prereq, like:\n\n test_lazy_prereq 64BIT_TIME '\n\tcase \"$(test-date show:short 9999999999)\" in\n\t*2038*)\n\t\tfalse\n\t\t;;\n\t*)\n\t\ttrue\n\t\t;;\n\tesac\n '\n\n ...\n check_show 64BIT_TIME iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\"\n check_show 64BIT_TIME iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\"\n\nThe main advantage is that it will number the tests consistently, and\ngive us a \"skipped\" message (which can remind us to drop the prereq\nlater when everything goes 64-bit).\n\nBut it also will do the right thing with test-date's output with respect\nto \"-v\" (not that we expect it to produce any output).\n\nYou'll need to adjust check_show as I did in my earlier patch.\n\n-Peff\n"},{"id":"291259","messageId":"20160712140603.GC613@sigill.intra.peff.net","threadId":"42823","inReplyTo":"57843C98.7020200@mit.edu","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-07-12T14:06:03Z","receivedAt":"2016-07-12T14:06:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 11, 2016 at 08:40:56PM -0400, Anders Kaseorg wrote:\n\n> On 07/11/2016 07:54 PM, Jeff King wrote:\n> > Yes, that's somewhat the point of the test.\n> > \n> > How does it fail for you (what does it look like with \"-v\")? We may be\n> > able to check for an outcome that matches both cases.\n> \n> On Ubuntu i386 and Ubuntu armhf, I get the following verbose output from\n> t0006-date.sh:\n> \n> \n> expecting success:\n> \t\techo \"$time -> $expect\" >expect &&\n> \t\ttest-date show:$format \"$time\" >actual &&\n> \t\ttest_cmp expect actual\n> \t\n> --- expect\t2016-07-11 23:20:55.835136188 +0000\n> +++ actual\t2016-07-11 23:20:55.835136188 +0000\n> @@ -1 +1 @@\n> -5758122296 -0400 -> 2152-06-19 18:24:56 -0400\n> +5758122296 -0400 -> 2038-01-18 23:14:07 -0400\n\nThank you for this, by the way. Your comment got drowned out by the rest\nof the thread, but this would have been very helpful for me in writing a\npatch (fortunately Dscho beat me to it, so I did not have to. :) ).\n\n-Peff\n"},{"id":"291260","messageId":"xmqqpoqj6i3d.fsf@gitster.mtv.corp.google.com","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607120927410.6426@virtualbox","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-12T14:34:14Z","receivedAt":"2016-07-12T14:34:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Git's source code assumes that unsigned long is at least as precise as\n> time_t. Well, Git's source code is wrong.\n> ...\n\nThat is correct. As people mentioned downthread already, \"unsigned\nlong\" has two problems, it may not be wide enough, and it cannot\nrepresent time before the epoch.\n\nBut moving the internal time representation used in various fields\nlike commit->date to time_t is likely to be a wrong thing to do,\nbecause the first problem with \"unsigned long\", i.e. \"may not be\nwide enough\", is not limited to \"not wide enough to hold time_t\".\nIt also includes \"it may not be wide enough to hold time somebody\nelse recorded in existing objects\".\n\nSince some platforms have time_t that is not wide enough, but still\nhave intmax_t that is wider, I think we would be better off to pick\nan integral type to use for the internal representation that is the\nwidest throughout the API, and use time_t only at places that we\ninteract with the system libraries (e.g. when we ask \"what is the\ntime now?\" to time(2), when we ask \"break down this timestamp\" to\ngmtime(3)).\n\nThanks for starting this, and from a brief read, the hotfix to skip\nthe test downthread looked good. The places this \"starting point\"\npatch covers look like a good set that interacts with time obtained\nlocally (e.g. prune that compares with filesystem timestamp); just\nmake sure you don't go too far and end up shoving timestamps from\nother people into time_t, which may not fit.\n\nThanks.\n\n\n\n\n"},{"id":"291264","messageId":"20160712151630.GE613@sigill.intra.peff.net","threadId":"42823","inReplyTo":"xmqqpoqj6i3d.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-07-12T15:16:30Z","receivedAt":"2016-07-12T15:16:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 12, 2016 at 07:34:14AM -0700, Junio C Hamano wrote:\n\n> > Git's source code assumes that unsigned long is at least as precise as\n> > time_t. Well, Git's source code is wrong.\n> > ...\n> \n> That is correct. As people mentioned downthread already, \"unsigned\n> long\" has two problems, it may not be wide enough, and it cannot\n> represent time before the epoch.\n> \n> But moving the internal time representation used in various fields\n> like commit->date to time_t is likely to be a wrong thing to do,\n> because the first problem with \"unsigned long\", i.e. \"may not be\n> wide enough\", is not limited to \"not wide enough to hold time_t\".\n> It also includes \"it may not be wide enough to hold time somebody\n> else recorded in existing objects\".\n\nBut that's a problem no matter what size we choose. The ascii format in\nthe commit objects is arbitrary-length, so somebody can always overflow\nit. So even with intmax_t we have to clamp it to a sentinel value at\nsome point. IMHO we are better off to do so at parse time, and then have\nconsistent sizes through the rest of the code base, without worrying\nabout juggling intmax_t to time_t truncation in multiple places.\n\nIOW, I think we probably interact with the system time libraries more\noften than we parse (and it's easy to wrap the parsing in a function,\nbut there are a lot of system time functions).\n\n-Peff\n"},{"id":"291265","messageId":"CAPc5daWcb5bfgsxMP0vCrQ7gBdeYBgefzPNHztaaCKzqbCv2aQ@mail.gmail.com","threadId":"42823","inReplyTo":"20160712151630.GE613@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-12T15:25:51Z","receivedAt":"2016-07-12T15:26:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Tue, Jul 12, 2016 at 8:16 AM, Jeff King wrote:\n>>\n>> But moving the internal time representation used in various fields\n>> like commit->date to time_t is likely to be a wrong thing to do,\n>> because the first problem with \"unsigned long\", i.e. \"may not be\n>> wide enough\", is not limited to \"not wide enough to hold time_t\".\n>> It also includes \"it may not be wide enough to hold time somebody\n>> else recorded in existing objects\".\n>\n> But that's a problem no matter what size we choose.\n\nYes, if somebody's time_t is larger than my intmax_t, the problem\ncannot be solved for me, if that timestamp is too far in the future or\nin the past.\n\nBut that is not the problem I am pointing out. I heard earlier in the\nthread that time_t on one system was 32-bit (was it Linux?) but I think\nthey have \"long long\". Choosing time_t is strictly inferior choice when\nwe already know that a platform with not-wide-enough time_t need to\nbe supported, and a type that is wider than that is available.\n\nI was envisioning that we would have typedef gittime_t\nwith conversion helpers between it and time_t that allow us to do some\nrange checks while at it.\n"},{"id":"291267","messageId":"20160712153520.GG613@sigill.intra.peff.net","threadId":"42823","inReplyTo":"CAPc5daWcb5bfgsxMP0vCrQ7gBdeYBgefzPNHztaaCKzqbCv2aQ@mail.gmail.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-07-12T15:35:20Z","receivedAt":"2016-07-12T15:35:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 12, 2016 at 08:25:51AM -0700, Junio C Hamano wrote:\n\n> On Tue, Jul 12, 2016 at 8:16 AM, Jeff King wrote:\n> >>\n> >> But moving the internal time representation used in various fields\n> >> like commit->date to time_t is likely to be a wrong thing to do,\n> >> because the first problem with \"unsigned long\", i.e. \"may not be\n> >> wide enough\", is not limited to \"not wide enough to hold time_t\".\n> >> It also includes \"it may not be wide enough to hold time somebody\n> >> else recorded in existing objects\".\n> >\n> > But that's a problem no matter what size we choose.\n> \n> Yes, if somebody's time_t is larger than my intmax_t, the problem\n> cannot be solved for me, if that timestamp is too far in the future or\n> in the past.\n\nI am less worried about their time_t and more about whatever crap they\nwrite in ascii into their objects. :)\n\n> But that is not the problem I am pointing out. I heard earlier in the\n> thread that time_t on one system was 32-bit (was it Linux?) but I think\n> they have \"long long\". Choosing time_t is strictly inferior choice when\n> we already know that a platform with not-wide-enough time_t need to\n> be supported, and a type that is wider than that is available.\n\nI am not certain that there is a modern system with 32-bit time_t. We\nknow there are systems with 32-bit unsigned long, and I think that is\nwhat produced the results people saw. I'd expect even 32-bit systems to\nuse \"int64_t\" or similar for their time_t these days.\n\nI'm also not convinced that we would be helping much to carry around a\nwider gittime_t. Most of the display code ends up touching a system time\nfunction one way or another, so I find it unlikely it would produce much\nbetter output.\n\nIt would help for simple cases like commit->date where we really do just\nparse it into a number and never do more with it. But...\n\n> I was envisioning that we would have typedef gittime_t\n> with conversion helpers between it and time_t that allow us to do some\n> range checks while at it.\n\nI guess I am just willing to trust that time_t is basically that. And if\nyour platform has a grossly undersized time_t, then too bad, we clamp\neverything it can't hold to 2038 or whatever, and hopefully your\nterrible platform dies out or gets a clue sometime in the next 20 years.\n\n-Peff\n"},{"id":"291268","messageId":"xmqqlh167tjd.fsf@gitster.mtv.corp.google.com","threadId":"42823","inReplyTo":"20160712153520.GG613@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-12T15:41:42Z","receivedAt":"2016-07-12T15:41:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I am not certain that there is a modern system with 32-bit time_t. We\n> know there are systems with 32-bit unsigned long, and I think that is\n> what produced the results people saw. I'd expect even 32-bit systems to\n> use \"int64_t\" or similar for their time_t these days.\n\nOK.\n"},{"id":"291272","messageId":"xmqqa8hm7swi.fsf@gitster.mtv.corp.google.com","threadId":"42823","inReplyTo":"20160712035719.GA30281@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-12T15:55:25Z","receivedAt":"2016-07-12T15:55:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> However, I was thinking that it might be handy to have this and some\n> other information available for helping with debugging. E.g., that we\n> could ask bug reporters for \"git version --build-options\" when we\n> suspect something related to their config.\n\nSure. I was wrong to phrase it as \"I would have...\"; either is fine\nby me, and being able to ask \"git version --build-options\" is\nprobably a plus.\n"},{"id":"291274","messageId":"20160712160921.GA2965@sigill.intra.peff.net","threadId":"42823","inReplyTo":"xmqqlh167tjd.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-07-12T16:09:21Z","receivedAt":"2016-07-12T16:09:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 12, 2016 at 08:41:42AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I am not certain that there is a modern system with 32-bit time_t. We\n> > know there are systems with 32-bit unsigned long, and I think that is\n> > what produced the results people saw. I'd expect even 32-bit systems to\n> > use \"int64_t\" or similar for their time_t these days.\n> \n> OK.\n\nIn case it wasn't clear, I was mostly guessing there. So I dug a bit\nfurther, and indeed, I am wrong. Linux never bumped to a 64-bit time_t\non i386 because of the ABI headaches.\n\nThat being said, I still think the \"clamp to time_t\" strategy is\nreasonable. Unless you are doing something really exotic like pretending\nto be from the future, nobody will care for 20 years. And at that point,\nsystems with a 32-bit time_t are going to have to do _something_,\nbecause time() is going to start returning bogus values. So as long as\nwe behave reasonably (e.g., clamping values and not generating wrapped\nnonsense), I think that's a fine solution.\n\n-Peff\n"},{"id":"291277","messageId":"xmqq60sa7rj2.fsf@gitster.mtv.corp.google.com","threadId":"42823","inReplyTo":"20160712160921.GA2965@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-12T16:25:05Z","receivedAt":"2016-07-12T16:25:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> In case it wasn't clear, I was mostly guessing there. So I dug a bit\n> further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t\n> on i386 because of the ABI headaches.\n\nX-< (yes, I knew).\n\n> That being said, I still think the \"clamp to time_t\" strategy is\n> reasonable. Unless you are doing something really exotic like pretending\n> to be from the future, nobody will care for 20 years.\n\nYup. It is a minor regression for them to go from ulong to time_t,\nbecause they didn't have to care for 90 years or so but now they do\nin 20 years, I'd guess, but hopefully after that many years,\neverybody's time_t would be sufficiently large.\n\nI suspect Cobol programmers in the 50s would have said a similar\nthing about the y2k timebomb they created back then, though ;-)\n\n> And at that point, systems with a 32-bit time_t are going to have\n> to do _something_, because time() is going to start returning\n> bogus values. So as long as we behave reasonably (e.g., clamping\n> values and not generating wrapped nonsense), I think that's a fine\n> solution.\n\nOK.\n"},{"id":"291288","messageId":"xmqqbn2267zq.fsf@gitster.mtv.corp.google.com","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607121257450.6426@virtualbox","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-12T18:12:25Z","receivedAt":"2016-07-12T18:12:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> Cool! Thanks for working on this.\n>\n> Well, I had to. Git for Windows v2.9.1 needs to get released, and I won't\n> do that with a failing test suite.\n\nLet's do 2.9.2 together, as this is not limited to GfW.\n\nTaking Peff's suggestions into account, perhaps like the attached?\n\nIt wasn't readily apparent to me why 2038 check worked, so I added a\nshort paragraph at the end, but those who know the test helper well\nenough may find it redundant, in which case I am fine with removing\nit.\n\nThanks.\n\n-- >8 --\nFrom: Johannes Schindelin \nDate: Tue, 12 Jul 2016 13:25:20 +0200\nSubject: t0006: skip \"far in the future\" test when ulong is not long enough\n\nGit's source code refers to timestamps as unsigned longs. On 32-bit\nplatforms, as well as on Windows, unsigned long is not large enough\nto capture dates that are \"absurdly far in the future\".\n\nWhile we can fix this issue properly by replacing unsigned long with\na larger type, we want to be a bit more conservative and just skip\nthose tests on the maint track.\n\nThe test helper reads the timestamp given from the command line into\n\"unsigned long\" using strtol(), which gives us LONG_MAX upon\noverflow, so feeding 9999999999 and seeing the resulting \"timestamp\"\nshown in year 2038 is a sufficient check for that condition.\n\nSigned-off-by: Johannes Schindelin \nHelped-by: Jeff King \nSigned-off-by: Junio C Hamano \n---\n t/t0006-date.sh | 18 +++++++++++++++---\n 1 file changed, 15 insertions(+), 3 deletions(-)\n\ndiff --git a/t/t0006-date.sh b/t/t0006-date.sh\nindex 04ce535..6070c29 100755\n--- a/t/t0006-date.sh\n+++ b/t/t0006-date.sh\n@@ -31,7 +31,7 @@ check_show () {\n \tformat=$1\n \ttime=$2\n \texpect=$3\n-\ttest_expect_${4:-success} \"show date ($format:$time)\" '\n+\ttest_expect_success $4 \"show date ($format:$time)\" '\n \t\techo \"$time -> $expect\" >expect &&\n \t\ttest-date show:$format \"$time\" >actual &&\n \t\ttest_cmp expect actual\n@@ -48,10 +48,22 @@ check_show default \"$TIME\" 'Wed Jun 15 16:13:20 2016 +0200'\n check_show raw \"$TIME\" '1466000000 +0200'\n check_show iso-local \"$TIME\" '2016-06-15 14:13:20 +0000'\n \n+test_lazy_prereq 64BIT_TIME '\n+\tcase \"$(test-date show:iso 9999999999)\" in\n+\t*\" -> 2038-\"*)\n+\t\t# on this platform, unsigned long is 32-bit, i.e. not large enough\n+\t\tfalse\n+\t\t;;\n+\t*)\n+\t\ttrue\n+\t\t;;\n+\tesac\n+'\n+\n # arbitrary time absurdly far in the future\n FUTURE=\"5758122296 -0400\"\n-check_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\"\n-check_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\"\n+check_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\" 64BIT_TIME\n+check_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\" 64BIT_TIME\n \n check_parse() {\n \techo \"$1 -> $2\" >expect\n-- \n2.9.1-500-g4c1e1e0\n\n\n\n"},{"id":"291289","messageId":"87a8hmpvte.fsf@linux-m68k.org","threadId":"42823","inReplyTo":"20160712160921.GA2965@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2016-07-12T18:15:09Z","receivedAt":"2016-07-12T18:15:20Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Jeff King writes:\n\n> In case it wasn't clear, I was mostly guessing there. So I dug a bit\n> further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t\n> on i386 because of the ABI headaches.\n\nThis is being worked on.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"291291","messageId":"CACsJy8CBGcKyMh9nbCAjZ=0T8TpoY9m98YJtgPFhQztVRPvXhg@mail.gmail.com","threadId":"42823","inReplyTo":"20160712134652.GA613@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-07-12T18:38:32Z","receivedAt":"2016-07-12T18:39:09Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Jul 12, 2016 at 3:46 PM, Jeff King wrote:\n> On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote:\n>\n>> Johannes Schindelin writes:\n>>\n>> > Hi Andreas,\n>> >\n>> > On Tue, 12 Jul 2016, Andreas Schwab wrote:\n>> >\n>> >> Johannes Schindelin writes:\n>> >>\n>> >> >> PRIuMAX isn't compatible with time_t.\n>> >> >\n>> >> > That statement is wrong.\n>> >>\n>> >> No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t\n>> >> (even if they happen to have the same representation).\n>> >\n>> > Sigh.\n>> >\n>> > So if it is wrong, what is right?\n>>\n>> The right thing is to add a cast, of course.\n>\n> In general, I think the right cast for time_t should be to (intmax_t),\n> and the formatting string should be PRIdMAX (which, as an aside, needs\n> an entry in git-compat-util.h).\n\nCoincidentally, I have the same problem with unsigned long being\n32-bit and have to switch to off_t in some places. Does anybody know\nwhat a fallback in git-compat-util for PRIdMAX would look like? I\nguess it's \"lld\"...\n-- \nDuy\n"},{"id":"291325","messageId":"CAPc5daXx=C82whkmoxkO7JSdG5gd=W=M4L0xsvQb12U2TKLJqQ@mail.gmail.com","threadId":"42823","inReplyTo":"xmqqbn2267zq.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-13T01:53:07Z","receivedAt":"2016-07-13T01:53:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Tue, Jul 12, 2016 at 11:12 AM, Junio C Hamano wrote:\n>\n> Let's do 2.9.2 together, as this is not limited to GfW.\n>\n> Taking Peff's suggestions into account, perhaps like the attached?\n\nIf I can get positive comments soon enough, I can do 2.9.2 early\ntomorrow my time.\nOr a reasonable counter-proposal (including \"without Peff's\nsuggestion, because...\")\nwould work well, too, for that.\n\nThanks.\n"},{"id":"291326","messageId":"20160713020132.GA13918@sigill.intra.peff.net","threadId":"42823","inReplyTo":"xmqqbn2267zq.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-07-13T02:01:33Z","receivedAt":"2016-07-13T02:03:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 12, 2016 at 11:12:25AM -0700, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> Cool! Thanks for working on this.\n> >\n> > Well, I had to. Git for Windows v2.9.1 needs to get released, and I won't\n> > do that with a failing test suite.\n> \n> Let's do 2.9.2 together, as this is not limited to GfW.\n> \n> Taking Peff's suggestions into account, perhaps like the attached?\n\nIt looks good to me.\n\n> It wasn't readily apparent to me why 2038 check worked, so I added a\n> short paragraph at the end, but those who know the test helper well\n> enough may find it redundant, in which case I am fine with removing\n> it.\n\nDefinitely keep that paragraph. I am quite familiar with the test\nhelper and it was not the outcome I initially expected.\n\n> +test_lazy_prereq 64BIT_TIME '\n> +\tcase \"$(test-date show:iso 9999999999)\" in\n> +\t*\" -> 2038-\"*)\n> +\t\t# on this platform, unsigned long is 32-bit, i.e. not large enough\n> +\t\tfalse\n\nI see you tightened up the match a little. TBH, I think we could\nprobably just match the whole output string, but I doubt there's much\nchance of a false positive either way.\n\n-Peff\n"},{"id":"291337","messageId":"alpine.DEB.2.20.1607131324121.6426@virtualbox","threadId":"42823","inReplyTo":"mvmd1mjdluz.fsf@hawking.suse.de","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-13T11:25:33Z","receivedAt":"2016-07-13T11:26:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Andreas,\n\nOn Tue, 12 Jul 2016, Andreas Schwab wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Tue, 12 Jul 2016, Andreas Schwab wrote:\n> >\n> >> Johannes Schindelin writes:\n> >> \n> >> >> PRIuMAX isn't compatible with time_t.\n> >> >\n> >> > That statement is wrong.\n> >> \n> >> No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t\n> >> (even if they happen to have the same representation).\n> >\n> > Sigh.\n> >\n> > So if it is wrong, what is right?\n> \n> The right thing is to add a cast, of course.\n\nThis was not helpful.\n\nCiao,\nJohannes\n"},{"id":"291338","messageId":"alpine.DEB.2.20.1607131326160.6426@virtualbox","threadId":"42823","inReplyTo":"CACsJy8CBGcKyMh9nbCAjZ=0T8TpoY9m98YJtgPFhQztVRPvXhg@mail.gmail.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-13T11:29:33Z","receivedAt":"2016-07-13T11:31:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Duy,\n\nOn Tue, 12 Jul 2016, Duy Nguyen wrote:\n\n> On Tue, Jul 12, 2016 at 3:46 PM, Jeff King wrote:\n> > On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote:\n> >\n> >> Johannes Schindelin writes:\n> >>\n> >> > On Tue, 12 Jul 2016, Andreas Schwab wrote:\n> >> >\n> >> >> Johannes Schindelin writes:\n> >> >>\n> >> >> >> PRIuMAX isn't compatible with time_t.\n> >> >> >\n> >> >> > That statement is wrong.\n> >> >>\n> >> >> No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t\n> >> >> (even if they happen to have the same representation).\n> >> >\n> >> > Sigh.\n> >> >\n> >> > So if it is wrong, what is right?\n> >>\n> >> The right thing is to add a cast, of course.\n> >\n> > In general, I think the right cast for time_t should be to (intmax_t),\n> > and the formatting string should be PRIdMAX (which, as an aside, needs\n> > an entry in git-compat-util.h).\n> \n> Coincidentally, I have the same problem with unsigned long being\n> 32-bit and have to switch to off_t in some places. Does anybody know\n> what a fallback in git-compat-util for PRIdMAX would look like? I\n> guess it's \"lld\"...\n\nYes, judging from the existing fallback for PRIuMAX, \"lld\" would be the\ncorrect thing to do. And then it would be nice to introduce\n\n\t#define PRIdMAX \"I64d\"\n\nnext to the PRIuMAX definition in compat/mingw.h, too.\n\nCiao,\nDscho\n"},{"id":"291339","messageId":"alpine.DEB.2.20.1607131329510.6426@virtualbox","threadId":"42823","inReplyTo":"20160712140427.GB613@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-13T11:35:31Z","receivedAt":"2016-07-13T11:36:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Tue, 12 Jul 2016, Jeff King wrote:\n\n> On Tue, Jul 12, 2016 at 01:25:20PM +0200, Johannes Schindelin wrote:\n> \n> > [PATCH] Work around test failures due to timestamps being unsigned long\n> > \n> > Git's source code refers to timestamps as unsigned longs. On 32-bit\n> > platforms, as well as on Windows, unsigned long is not large enough to\n> > capture dates that are \"absurdly far in the future\".\n> > \n> > While we will fix this issue properly by replacing unsigned long ->\n> > time_t, on the maint track we want to be a bit more conservative and\n> > just skip those tests.\n> > \n> > Signed-off-by: Johannes Schindelin \n> > ---\n> \n> This looks like a reasonable interim fix for both Windows and for the\n> general maint track. If we reliably produce \"2038\" for the 999... value\n> then that's simpler than adding in magic to ask about sizeof(ulong). I\n> also wondered if we should test forthe _correct_ value, but that would\n> defeat the point of the test (999... is also far in the future).\n\nThis was just a quick fix, intended to allow me to release Git for Windows\nv2.9.1 in a timely manner (which is now delayed for other reasons).\n\nI think I can do even better than to inspect the source code whether it\nreliably clamps the dates to PI hours on January 19th, 2038: We already\nhave a t/helper/test-date and we can easily teach it one new trick.\n\n> One minor comment:\n> \n> > diff --git a/t/t0006-date.sh b/t/t0006-date.sh\n> > index 04ce535..d185640 100755\n> > --- a/t/t0006-date.sh\n> > +++ b/t/t0006-date.sh\n> > @@ -48,10 +48,17 @@ check_show default \"$TIME\" 'Wed Jun 15 16:13:20 2016 +0200'\n> > check_show raw \"$TIME\" '1466000000 +0200'\n> > check_show iso-local \"$TIME\" '2016-06-15 14:13:20 +0000'\n> > \n> > -# arbitrary time absurdly far in the future\n> > -FUTURE=\"5758122296 -0400\"\n> > -check_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\"\n> > -check_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\"\n> > +case \"$(test-date show:iso 9999999999)\" in\n> > +*2038*)\n> > +\t# on this platform, unsigned long is 32-bit, i.e. not large enough\n> > +\t;;\n> > +*)\n> > +\t# arbitrary time absurdly far in the future\n> > +\tFUTURE=\"5758122296 -0400\"\n> > +\tcheck_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\"\n> > +\tcheck_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\"\n> > +\t;;\n> > +esac\n> \n> It would be nice to wrap this in a prereq, like:\n> \n> test_lazy_prereq 64BIT_TIME '\n> \tcase \"$(test-date show:short 9999999999)\" in\n> \t*2038*)\n> \t\tfalse\n> \t\t;;\n> \t*)\n> \t\ttrue\n> \t\t;;\n> \tesac\n> '\n> \n> ...\n> check_show 64BIT_TIME iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\"\n> check_show 64BIT_TIME iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\"\n> \n> The main advantage is that it will number the tests consistently, and\n> give us a \"skipped\" message (which can remind us to drop the prereq\n> later when everything goes 64-bit).\n> \n> But it also will do the right thing with test-date's output with respect\n> to \"-v\" (not that we expect it to produce any output).\n> \n> You'll need to adjust check_show as I did in my earlier patch.\n\nMakes sense!\n\nThanks,\nDscho\n"},{"id":"291341","messageId":"alpine.DEB.2.20.1607131600110.6426@virtualbox","threadId":"42823","inReplyTo":"xmqq60sa7rj2.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-13T14:00:46Z","receivedAt":"2016-07-13T14:05:03Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 12 Jul 2016, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > In case it wasn't clear, I was mostly guessing there. So I dug a bit\n> > further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t\n> > on i386 because of the ABI headaches.\n> \n> X-< (yes, I knew).\n> \n> > That being said, I still think the \"clamp to time_t\" strategy is\n> > reasonable. Unless you are doing something really exotic like pretending\n> > to be from the future, nobody will care for 20 years.\n> \n> Yup. It is a minor regression for them to go from ulong to time_t,\n> because they didn't have to care for 90 years or so but now they do\n> in 20 years, I'd guess, but hopefully after that many years,\n> everybody's time_t would be sufficiently large.\n> \n> I suspect Cobol programmers in the 50s would have said a similar\n> thing about the y2k timebomb they created back then, though ;-)\n> \n> > And at that point, systems with a 32-bit time_t are going to have\n> > to do _something_, because time() is going to start returning\n> > bogus values. So as long as we behave reasonably (e.g., clamping\n> > values and not generating wrapped nonsense), I think that's a fine\n> > solution.\n> \n> OK.\n\nI kept the unsigned long -> time_t conversion after reading the thread so\nfar.\n\nCiao,\nDscho\n"},{"id":"291358","messageId":"xmqqlh1534qk.fsf@gitster.mtv.corp.google.com","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607131329510.6426@virtualbox","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-13T16:03:15Z","receivedAt":"2016-07-13T16:05:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> This was just a quick fix, intended to allow me to release Git for Windows\n> v2.9.1 in a timely manner (which is now delayed for other reasons).\n> ...\n>> You'll need to adjust check_show as I did in my earlier patch.\n>\n> Makes sense!\n\nHmph, so what is your preferred approach? You'll do your own v2.9.1\nthat is different from others at t0006?\n\nI was hoping to hear from you sooner and do v2.9.2 with your t0006\nworkaround with lazy-prereq changes from Peff (i.e. \"Makes sense!\"\nabove), so that you do not have to do two releases in a row\n(i.e. skipping v2.9.1 saying \"Git for Windows skipped that one\nbecause it was not quite right; this release fixes the issue\" in\nyour v2.9.2 announcement).\n\nThanks.\n"},{"id":"291359","messageId":"xmqqh9bt34n1.fsf@gitster.mtv.corp.google.com","threadId":"42823","inReplyTo":"20160713020132.GA13918@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-13T16:05:22Z","receivedAt":"2016-07-13T16:06:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Definitely keep that paragraph. I am quite familiar with the test\n> helper and it was not the outcome I initially expected.\n>\n>> +test_lazy_prereq 64BIT_TIME '\n>> +\tcase \"$(test-date show:iso 9999999999)\" in\n>> +\t*\" -> 2038-\"*)\n>> +\t\t# on this platform, unsigned long is 32-bit, i.e. not large enough\n>> +\t\tfalse\n>\n> I see you tightened up the match a little. TBH, I think we could\n> probably just match the whole output string, but I doubt there's much\n> chance of a false positive either way.\n\nAh, it wasn't meant to be a tightening; rather the above is for\ndocumentation value, i.e. make it stand out what 2038 we are\nmatching---its answer being \"the year portion of the result of the\nconversion\".\n\n"},{"id":"291360","messageId":"xmqqd1mh34eh.fsf@gitster.mtv.corp.google.com","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607131600110.6426@virtualbox","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-13T16:10:30Z","receivedAt":"2016-07-13T16:13:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Tue, 12 Jul 2016, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>> \n>> > In case it wasn't clear, I was mostly guessing there. So I dug a bit\n>> > further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t\n>> > on i386 because of the ABI headaches.\n>> \n>> X-< (yes, I knew).\n>> \n>> > That being said, I still think the \"clamp to time_t\" strategy is\n>> > reasonable. Unless you are doing something really exotic like pretending\n>> > to be from the future, nobody will care for 20 years.\n>> \n>> Yup. It is a minor regression for them to go from ulong to time_t,\n>> because they didn't have to care for 90 years or so but now they do\n>> in 20 years, I'd guess, but hopefully after that many years,\n>> everybody's time_t would be sufficiently large.\n>> \n>> I suspect Cobol programmers in the 50s would have said a similar\n>> thing about the y2k timebomb they created back then, though ;-)\n>> \n>> > And at that point, systems with a 32-bit time_t are going to have\n>> > to do _something_, because time() is going to start returning\n>> > bogus values. So as long as we behave reasonably (e.g., clamping\n>> > values and not generating wrapped nonsense), I think that's a fine\n>> > solution.\n>> \n>> OK.\n>\n> I kept the unsigned long -> time_t conversion after reading the thread so\n> far.\n\nThat's OK at this point; it is not v2.9.x material anyway.\n\nThe primary reason why I cared 32-bit time_t is not about 2038, by\nthe way. I recall that people wanted to store historical document\nwith ancient timestamp; even if we update to support negative\ntimestamps, they cannot go back to 19th century with 32-bit time_t,\nbut they can with long long or whatever intmax_t is on their system.\n"},{"id":"291378","messageId":"alpine.DEB.2.20.1607132048370.6426@virtualbox","threadId":"42823","inReplyTo":"xmqqh9bt34n1.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-13T18:52:14Z","receivedAt":"2016-07-13T18:53:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 13 Jul 2016, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Definitely keep that paragraph. I am quite familiar with the test\n> > helper and it was not the outcome I initially expected.\n> >\n> >> +test_lazy_prereq 64BIT_TIME '\n> >> +\tcase \"$(test-date show:iso 9999999999)\" in\n> >> +\t*\" -> 2038-\"*)\n> >> +\t\t# on this platform, unsigned long is 32-bit, i.e. not large enough\n> >> +\t\tfalse\n> >\n> > I see you tightened up the match a little. TBH, I think we could\n> > probably just match the whole output string, but I doubt there's much\n> > chance of a false positive either way.\n> \n> Ah, it wasn't meant to be a tightening; rather the above is for\n> documentation value, i.e. make it stand out what 2038 we are\n> matching---its answer being \"the year portion of the result of the\n> conversion\".\n\nHow about this one instead (which is part of the time_t-may-be-int64\nbranch on https://github.com/dscho/git which I still have to complete, as\nsome unsigned longs still slipped out of my previous net)? It strikes me\nas much more robust:\n\n-- snipsnap --\nFrom abe59dbb2235bb1d7aad8e78a66e196acb372ec8 Mon Sep 17 00:00:00 2001\nFrom: Johannes Schindelin \nDate: Tue, 12 Jul 2016 13:19:53 +0200\nSubject: [PATCH] t0006: dates absurdly far require a 64-bit data type\n\nGit's source code refers to timestamps as unsigned longs. On 32-bit\nplatforms, as well as on Windows, unsigned long is not large enough to\ncapture dates that are \"absurdly far in the future\".\n\nLet's skip those tests if we know they cannot succeed.\n\nSigned-off-by: Johannes Schindelin \n---\n t/helper/test-date.c | 5 ++++-\n t/t0006-date.sh | 6 +++---\n t/test-lib.sh | 2 ++\n 3 files changed, 9 insertions(+), 4 deletions(-)\n\ndiff --git a/t/helper/test-date.c b/t/helper/test-date.c\nindex d9ab360..1e12d93 100644\n--- a/t/helper/test-date.c\n+++ b/t/helper/test-date.c\n@@ -4,7 +4,8 @@ static const char *usage_msg = \"\\n\"\n \" test-date relative [time_t]...\\n\"\n \" test-date show: [time_t]...\\n\"\n \" test-date parse [date]...\\n\"\n-\" test-date approxidate [date]...\\n\";\n+\" test-date approxidate [date]...\\n\"\n+\" test-date is64bit\\n\";\n \n static void show_relative_dates(char **argv, struct timeval *now)\n {\n@@ -93,6 +94,8 @@ int main(int argc, char **argv)\n \t\tparse_dates(argv+1, &now);\n \telse if (!strcmp(*argv, \"approxidate\"))\n \t\tparse_approxidate(argv+1, &now);\n+\telse if (!strcmp(*argv, \"is64bit\"))\n+\t\treturn sizeof(unsigned long) == 8 ? 0 : 1;\n \telse\n \t\tusage(usage_msg);\n \treturn 0;\ndiff --git a/t/t0006-date.sh b/t/t0006-date.sh\nindex 04ce535..52f6b62 100755\n--- a/t/t0006-date.sh\n+++ b/t/t0006-date.sh\n@@ -31,7 +31,7 @@ check_show () {\n \tformat=$1\n \ttime=$2\n \texpect=$3\n-\ttest_expect_${4:-success} \"show date ($format:$time)\" '\n+\ttest_expect_success $4 \"show date ($format:$time)\" '\n \t\techo \"$time -> $expect\" >expect &&\n \t\ttest-date show:$format \"$time\" >actual &&\n \t\ttest_cmp expect actual\n@@ -50,8 +50,8 @@ check_show iso-local \"$TIME\" '2016-06-15 14:13:20 +0000'\n \n # arbitrary time absurdly far in the future\n FUTURE=\"5758122296 -0400\"\n-check_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\"\n-check_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\"\n+check_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\" 64BITTIME\n+check_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\" 64BITTIME\n \n check_parse() {\n \techo \"$1 -> $2\" >expect\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 0055ebb..4e1afb0 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -1111,3 +1111,5 @@ run_with_limited_cmdline () {\n }\n \n test_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'\n+\n+test_lazy_prereq 64BITTIME 'test-date is64bit'\n-- \n2.9.0.278.g1caae67\n\n"},{"id":"291379","messageId":"alpine.DEB.2.20.1607132052520.6426@virtualbox","threadId":"42823","inReplyTo":"xmqqd1mh34eh.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-13T18:53:46Z","receivedAt":"2016-07-13T18:55:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 13 Jul 2016, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Tue, 12 Jul 2016, Junio C Hamano wrote:\n> >\n> >> Jeff King writes:\n> >> \n> >> > In case it wasn't clear, I was mostly guessing there. So I dug a bit\n> >> > further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t\n> >> > on i386 because of the ABI headaches.\n> >> \n> >> X-< (yes, I knew).\n> >> \n> >> > That being said, I still think the \"clamp to time_t\" strategy is\n> >> > reasonable. Unless you are doing something really exotic like pretending\n> >> > to be from the future, nobody will care for 20 years.\n> >> \n> >> Yup. It is a minor regression for them to go from ulong to time_t,\n> >> because they didn't have to care for 90 years or so but now they do\n> >> in 20 years, I'd guess, but hopefully after that many years,\n> >> everybody's time_t would be sufficiently large.\n> >> \n> >> I suspect Cobol programmers in the 50s would have said a similar\n> >> thing about the y2k timebomb they created back then, though ;-)\n> >> \n> >> > And at that point, systems with a 32-bit time_t are going to have\n> >> > to do _something_, because time() is going to start returning\n> >> > bogus values. So as long as we behave reasonably (e.g., clamping\n> >> > values and not generating wrapped nonsense), I think that's a fine\n> >> > solution.\n> >> \n> >> OK.\n> >\n> > I kept the unsigned long -> time_t conversion after reading the thread so\n> > far.\n> \n> That's OK at this point; it is not v2.9.x material anyway.\n\nGot it. I will try to get the patches submitted soon, anyway.\n\n> The primary reason why I cared 32-bit time_t is not about 2038, by\n> the way. I recall that people wanted to store historical document\n> with ancient timestamp; even if we update to support negative\n> timestamps, they cannot go back to 19th century with 32-bit time_t,\n> but they can with long long or whatever intmax_t is on their system.\n\nFair enough.\n\nCiao,\nDscho\n"},{"id":"291384","messageId":"xmqq8tx51hmx.fsf@gitster.mtv.corp.google.com","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607132048370.6426@virtualbox","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-13T19:07:34Z","receivedAt":"2016-07-13T19:08:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> How about this one instead (which is part of the time_t-may-be-int64\n> branch on https://github.com/dscho/git which I still have to complete, as\n> some unsigned longs still slipped out of my previous net)? It strikes me\n> as much more robust:\n\nHmm, sorry, I do not see much upside here (iow, the 2038 test you\ncame up with is as robust). When the internal time representation\nis updated from \"unsigned long\" to a signed and wider type [*1*],\ntest-date has to stop reading the second-from-epoch input with\nstrtol(), whose property that overflow will always result in\nLONG_MAX gives the robustness of the 2038 test, and needs to be\nupdated. With this \"is64bit\" patch, you explicitly measure\n\"unsigned long\", knowing that our internal time representation\ncurrently is that type, and that would need to be updated when\nwidening happens. So both need to be updated anyway in the future.\n\nThe update to check_show Peff suggested is the same as the previous\none, so there is no upside nor downside.\n\nThe prerequisite name 64BITTIME that lost an underscore is harder to\nread, so there is a slight downside.\n\nMoving of lazy_prereq to test-lib might be an upside if we were\nplanning to add a test that depends on the system having or not\nhaving 64-bit timestamp elsewhere, but I do not think of a reason\nwhy such a new test cannot go to t0006-date, which has the perfect\nname for such a test and is not overly long right now (114 lines).\n\nSo, unless you have a more solid reason to reject the updated t0006\nearlier in the thread, I am not sure what we'd gain by replacing it\nwith this version.\n\n\n> -- snipsnap --\n> From abe59dbb2235bb1d7aad8e78a66e196acb372ec8 Mon Sep 17 00:00:00 2001\n> From: Johannes Schindelin \n> Date: Tue, 12 Jul 2016 13:19:53 +0200\n> Subject: [PATCH] t0006: dates absurdly far require a 64-bit data type\n>\n> Git's source code refers to timestamps as unsigned longs. On 32-bit\n> platforms, as well as on Windows, unsigned long is not large enough to\n> capture dates that are \"absurdly far in the future\".\n>\n> Let's skip those tests if we know they cannot succeed.\n>\n> Signed-off-by: Johannes Schindelin \n> ---\n> t/helper/test-date.c | 5 ++++-\n> t/t0006-date.sh | 6 +++---\n> t/test-lib.sh | 2 ++\n> 3 files changed, 9 insertions(+), 4 deletions(-)\n>\n> diff --git a/t/helper/test-date.c b/t/helper/test-date.c\n> index d9ab360..1e12d93 100644\n> --- a/t/helper/test-date.c\n> +++ b/t/helper/test-date.c\n> @@ -4,7 +4,8 @@ static const char *usage_msg = \"\\n\"\n> \" test-date relative [time_t]...\\n\"\n> \" test-date show: [time_t]...\\n\"\n> \" test-date parse [date]...\\n\"\n> -\" test-date approxidate [date]...\\n\";\n> +\" test-date approxidate [date]...\\n\"\n> +\" test-date is64bit\\n\";\n> \n> static void show_relative_dates(char **argv, struct timeval *now)\n> {\n> @@ -93,6 +94,8 @@ int main(int argc, char **argv)\n> \t\tparse_dates(argv+1, &now);\n> \telse if (!strcmp(*argv, \"approxidate\"))\n> \t\tparse_approxidate(argv+1, &now);\n> +\telse if (!strcmp(*argv, \"is64bit\"))\n> +\t\treturn sizeof(unsigned long) == 8 ? 0 : 1;\n> \telse\n> \t\tusage(usage_msg);\n> \treturn 0;\n> diff --git a/t/t0006-date.sh b/t/t0006-date.sh\n> index 04ce535..52f6b62 100755\n> --- a/t/t0006-date.sh\n> +++ b/t/t0006-date.sh\n> @@ -31,7 +31,7 @@ check_show () {\n> \tformat=$1\n> \ttime=$2\n> \texpect=$3\n> -\ttest_expect_${4:-success} \"show date ($format:$time)\" '\n> +\ttest_expect_success $4 \"show date ($format:$time)\" '\n> \t\techo \"$time -> $expect\" >expect &&\n> \t\ttest-date show:$format \"$time\" >actual &&\n> \t\ttest_cmp expect actual\n> @@ -50,8 +50,8 @@ check_show iso-local \"$TIME\" '2016-06-15 14:13:20 +0000'\n> \n> # arbitrary time absurdly far in the future\n> FUTURE=\"5758122296 -0400\"\n> -check_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\"\n> -check_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\"\n> +check_show iso \"$FUTURE\" \"2152-06-19 18:24:56 -0400\" 64BITTIME\n> +check_show iso-local \"$FUTURE\" \"2152-06-19 22:24:56 +0000\" 64BITTIME\n> \n> check_parse() {\n> \techo \"$1 -> $2\" >expect\n> diff --git a/t/test-lib.sh b/t/test-lib.sh\n> index 0055ebb..4e1afb0 100644\n> --- a/t/test-lib.sh\n> +++ b/t/test-lib.sh\n> @@ -1111,3 +1111,5 @@ run_with_limited_cmdline () {\n> }\n> \n> test_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'\n> +\n> +test_lazy_prereq 64BITTIME 'test-date is64bit'\n"},{"id":"291385","messageId":"alpine.DEB.2.20.1607132105091.6426@virtualbox","threadId":"42823","inReplyTo":"xmqqlh1534qk.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-13T19:10:29Z","receivedAt":"2016-07-13T19:10:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 13 Jul 2016, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > This was just a quick fix, intended to allow me to release Git for Windows\n> > v2.9.1 in a timely manner (which is now delayed for other reasons).\n> > ...\n> >> You'll need to adjust check_show as I did in my earlier patch.\n> >\n> > Makes sense!\n> \n> Hmph, so what is your preferred approach? You'll do your own v2.9.1\n> that is different from others at t0006?\n\nI may do a Git for Windows v2.9.1 that is different from Git v2.9.1 in\nt0006, yes. Git for Windows still has tons of patches on top of Git\nbecause I seem to be unable to drain the patch queue as fast as I want, so\nI do not believe it is a big deal.\n\n> I was hoping to hear from you sooner and do v2.9.2 with your t0006\n> workaround with lazy-prereq changes from Peff (i.e. \"Makes sense!\"\n> above), so that you do not have to do two releases in a row\n> (i.e. skipping v2.9.1 saying \"Git for Windows skipped that one\n> because it was not quite right; this release fixes the issue\" in\n> your v2.9.2 announcement).\n\nI am sorry that you expected me to be more available. It is a pretty crazy\nweek already (and trying to get a Git for Windows v2.9.1 out of the door\nafter dropping everything else on Tuesday morning added quite a bit to the\nload), so I am at times unable to even read the Git mailing list.\n\nAs I am more concerned with Jeff Hostetler's patch now (the \"very verbose\nporcelain status\"; I merged the Pull Request after seeing no comments on\nhis mail, but then Peff provided some good feedback, so now I am not quite\ncertain how to go about it: revert, or wait if the 2nd iteration is\nacceptable and take that), so I am not immediately releasing any version,\nanyway.\n\nCiao,\nDscho\n"},{"id":"291388","messageId":"xmqqvb09z5p7.fsf@gitster.mtv.corp.google.com","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607132105091.6426@virtualbox","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-13T19:41:24Z","receivedAt":"2016-07-13T19:41:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> I was hoping to hear from you sooner and do v2.9.2 with your t0006\n>> workaround with lazy-prereq changes from Peff (i.e. \"Makes sense!\"\n>> above), so that you do not have to do two releases in a row\n>> (i.e. skipping v2.9.1 saying \"Git for Windows skipped that one\n>> because it was not quite right; this release fixes the issue\" in\n>> your v2.9.2 announcement).\n>\n> I am sorry that you expected me to be more available. It is a pretty crazy\n> week already (and trying to get a Git for Windows v2.9.1 out of the door\n> after dropping everything else on Tuesday morning added quite a bit to the\n> load), so I am at times unable to even read the Git mailing list.\n\nActually these back-and-forth was an attempt to help you reduce the\nload by not having to worry about the t0006 workaround. Checking\nyour inbox would have been quicker than writing another of your own\nversion.\n\n> As I am more concerned with Jeff Hostetler's patch now (the \"very verbose\n> porcelain status\"; I merged the Pull Request after seeing no comments on\n> his mail, but then Peff provided some good feedback, so now I am not quite\n> certain how to go about it: revert, or wait if the 2nd iteration is\n> acceptable and take that), so I am not immediately releasing any version,\n> anyway.\n\nAs I said, I'd be waiting for a reroll of that to queue on 'pu', but\nas a new feature, it won't appear in any of the v2.9.x releases.\n"},{"id":"291392","messageId":"xmqqmvllz2t7.fsf@gitster.mtv.corp.google.com","threadId":"42823","inReplyTo":"xmqqy4577h0o.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-13T20:43:48Z","receivedAt":"2016-07-13T20:43:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> It is somewhat disturbing that nobody seems to be regularly building\n> on 32-bit platforms these days, which is the only reason I can think\n> of why this was never reported until it hit a maintenance track.\n> This should have been caught last week at f6a729f3 (Merge branch\n> 'jk/tzoffset-fix', 2016-07-06) when the topic hit 'master' at the\n> latest, and more preferrably it should have already been caught last\n> month at 08ec8c5e (Merge branch 'jk/tzoffset-fix' into next,\n> 2016-06-28).\n>\n> Those who care about 32-bit builds need to start building and\n> testing 'next' and 'master' regularly, or similar breakages are\n> bound to continue happening X-<.\n>\n> Volunteers?\n\nWe might eventually see a volunteer or two but that hasn't happened\nyet, at least in the past few days.\n\nDoes Travis CI testing have an option to run our tests on some\n32-bit platforms?\n"},{"id":"291401","messageId":"F003C6A7-CF52-4149-9A05-8DDA549BABEE@gmail.com","threadId":"42823","inReplyTo":"xmqqmvllz2t7.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-07-14T07:38:27Z","receivedAt":"2016-07-14T07:38:29Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 13 Jul 2016, at 22:43, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n>> It is somewhat disturbing that nobody seems to be regularly building\n>> on 32-bit platforms these days, which is the only reason I can think\n>> of why this was never reported until it hit a maintenance track.\n>> This should have been caught last week at f6a729f3 (Merge branch\n>> 'jk/tzoffset-fix', 2016-07-06) when the topic hit 'master' at the\n>> latest, and more preferrably it should have already been caught last\n>> month at 08ec8c5e (Merge branch 'jk/tzoffset-fix' into next,\n>> 2016-06-28).\n>> \n>> Those who care about 32-bit builds need to start building and\n>> testing 'next' and 'master' regularly, or similar breakages are\n>> bound to continue happening X-<.\n>> \n>> Volunteers?\n> \n> We might eventually see a volunteer or two but that hasn't happened\n> yet, at least in the past few days.\n> \n> Does Travis CI testing have an option to run our tests on some\n> 32-bit platforms?\n\nTravisCI does not support 32-bit platforms natively:\nhttps://github.com/travis-ci/travis-ci/issues/986#issuecomment-124141683\n\nHowever, there seems to be a way to enter a 32 bit Trusty chroot on \n64 bit Travis via Docker:\nhttps://github.com/travis-ci/travis-ci/issues/5770\n\n@Duy:\nYou mentioned that you compiled Git on Docker before ($gmane/297963). \nWhat do you think the chroot approach? Could that work? Would that\nbe reliable?\n\n@Sid:\nDoes GitLab CI support 32-bit platforms?\n\nThanks,\nLars\n"},{"id":"291402","messageId":"alpine.DEB.2.20.1607140913470.6426@virtualbox","threadId":"42823","inReplyTo":"xmqq8tx51hmx.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-14T07:45:12Z","receivedAt":"2016-07-14T07:45:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 13 Jul 2016, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > How about this one instead (which is part of the time_t-may-be-int64\n> > branch on https://github.com/dscho/git which I still have to complete, as\n> > some unsigned longs still slipped out of my previous net)? It strikes me\n> > as much more robust:\n> \n> Hmm, sorry, I do not see much upside here (iow, the 2038 test you\n> came up with is as robust).\n\nUnless you, or Peff, performed a thorough analysis whether the dates are\nalways cut off at 2038 holds true, I am highly doubtful that the previous\ntes is robust at all. I certainly only tested on Windows and never\ninvestigated how that 2038 came about. For what I know, it might be a\nplatform-dependent behavior of strtoul().\n\n> When the internal time representation is updated from \"unsigned long\" to\n> a signed and wider type [*1*], test-date has to stop reading the\n> second-from-epoch input with strtol(),\n\nIt's strtoul(), actually.\n\n> whose property that overflow will always result in LONG_MAX gives the\n> robustness of the 2038 test, and needs to be updated.\n\nSo I got curious and looked at the man page. It says indeed that strtoul()\nreturns ULONG_MAX, which happens to translate into a date in the year\n2038. It seems that this behavior is standardized:\n\n\thttp://pubs.opengroup.org/onlinepubs/007908775/xsh/strtoul.html\n\nalthough it does not say that ANSI C requires that behavior.\n\nI also could not fail to notice that negative values will be parsed and\nsimply negated, and that return values 0 and ULONG_MAX *can* denote errors\n(in which case errno is set, otherwise it is *not* set). Two rather\nsurprising facts, at least surprising to me, and facts that our code does\nnot deal with.\n\nPlease also note that ULONG_MAX is not required to be either 2^32-1 or\n2^64-1. Which means that the 2038 test is really not robust.\n\n> With this \"is64bit\" patch, you explicitly measure \"unsigned long\",\n> knowing that our internal time representation currently is that type,\n> and that would need to be updated when widening happens. So both need\n> to be updated anyway in the future.\n\nYes, I already update that in my topic branch.\n\nPlease note, however, that it is much more natural to update yet another\ninstance of \"unsigned long\" to \"time_t\" than having to explain how that\n2038 test is affected.\n\nAlso note that the 640bit test is very explicit, and hence robust. As a\nconsequence it would skip the absurd dates on systems switching to\nint128_t for time_t.\n\n> The prerequisite name 64BITTIME that lost an underscore is harder to\n> read, so there is a slight downside.\n\nIt is not a downside. It is something easily fixed.\n\n> Moving of lazy_prereq to test-lib might be an upside if we were\n> planning to add a test that depends on the system having or not\n> having 64-bit timestamp elsewhere, but I do not think of a reason\n> why such a new test cannot go to t0006-date, which has the perfect\n> name for such a test and is not overly long right now (114 lines).\n\nHappenstance. And I was merely imitating the patch of Peff thar I found on\ngmane.\n\n> So, unless you have a more solid reason to reject the updated t0006\n> earlier in the thread, I am not sure what we'd gain by replacing it\n> with this version.\n\nMy solid reason is that it is utterky unobvious why the magic number 2038\nshould do the work. You would have to spend quite some time to convince\nthe average programmer that it is correct.\n\nContrast that to the 64-bit test.\n\nCiao,\nDscho\n"},{"id":"291403","messageId":"alpine.DEB.2.20.1607140945520.6426@virtualbox","threadId":"42823","inReplyTo":"xmqqvb09z5p7.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-14T07:50:33Z","receivedAt":"2016-07-14T07:50:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 13 Jul 2016, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> I was hoping to hear from you sooner and do v2.9.2 with your t0006\n> >> workaround with lazy-prereq changes from Peff (i.e. \"Makes sense!\"\n> >> above), so that you do not have to do two releases in a row (i.e.\n> >> skipping v2.9.1 saying \"Git for Windows skipped that one because it\n> >> was not quite right; this release fixes the issue\" in your v2.9.2\n> >> announcement).\n> >\n> > I am sorry that you expected me to be more available. It is a pretty\n> > crazy week already (and trying to get a Git for Windows v2.9.1 out of\n> > the door after dropping everything else on Tuesday morning added quite\n> > a bit to the load), so I am at times unable to even read the Git\n> > mailing list.\n> \n> Actually these back-and-forth was an attempt to help you reduce the load\n> by not having to worry about the t0006 workaround. Checking your inbox\n> would have been quicker than writing another of your own version.\n\nIn this instance, you're correct. I made it a habit of not checking the\ninbox at all when in the zone, though. Certainly when the time zone\ndifference virtually guarantee that your work hours and mine do not\noverlap (the announcement of Git v2.9.1 arrived around 4h after I logged\noff for the day, for example).\n\n> > As I am more concerned with Jeff Hostetler's patch now (the \"very\n> > verbose porcelain status\"; I merged the Pull Request after seeing no\n> > comments on his mail, but then Peff provided some good feedback, so\n> > now I am not quite certain how to go about it: revert, or wait if the\n> > 2nd iteration is acceptable and take that), so I am not immediately\n> > releasing any version, anyway.\n> \n> As I said, I'd be waiting for a reroll of that to queue on 'pu', but as\n> a new feature, it won't appear in any of the v2.9.x releases.\n\nYes, the feature will appear in some v2.9.x release: in Git for Windows.\n\nCiao,\nDscho\n"},{"id":"291404","messageId":"alpine.DEB.2.20.1607140952160.6426@virtualbox","threadId":"42823","inReplyTo":"xmqqmvllz2t7.fsf@gitster.mtv.corp.google.com","subject":"32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-14T07:58:45Z","receivedAt":"2016-07-14T07:59:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 13 Jul 2016, Junio C Hamano wrote:\n\n> Does Travis CI testing have an option to run our tests on some\n> 32-bit platforms?\n\nAFAIR Docker does not support 32-bit, and IIRC that's what Travis uses.\n\nHowever, it is possible to install a 32-bit toolchain and use that to\ncompile Git.\n\nIt would be even easier with MacOSX because XCode's gcc can target both\narchitectures. Simply adding the -m32 CFLAG/LDFLAG might be enough.\n\nSadly, I lack the time to investigate further. Sounds like a fun project.\n\nCiao,\nDscho\n"},{"id":"291405","messageId":"mvmr3awbqc9.fsf@hawking.suse.de","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607140913470.6426@virtualbox","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2016-07-14T08:01:42Z","receivedAt":"2016-07-14T08:02:18Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Johannes Schindelin writes:\n\n> So I got curious and looked at the man page. It says indeed that strtoul()\n> returns ULONG_MAX, which happens to translate into a date in the year\n> 2038.\n\n4294967295 would rather be 2106.\n\n$ date -d @$((0xffffffff))\nSo 7. Feb 07:28:15 CET 2106\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"291407","messageId":"20160714081503.GA12946@sigill.intra.peff.net","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607140913470.6426@virtualbox","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-07-14T08:15:04Z","receivedAt":"2016-07-14T08:15:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"tl;dr I don't really care which fix goes in. They are both fine with me,\nand in practice I cannot imagine either causing a big problem. But here\nare my thoughts because I know you want them.\n\nOn Thu, Jul 14, 2016 at 09:45:12AM +0200, Johannes Schindelin wrote:\n\n> > Hmm, sorry, I do not see much upside here (iow, the 2038 test you\n> > came up with is as robust).\n> \n> Unless you, or Peff, performed a thorough analysis whether the dates are\n> always cut off at 2038 holds true, I am highly doubtful that the previous\n> tes is robust at all. I certainly only tested on Windows and never\n> investigated how that 2038 came about. For what I know, it might be a\n> platform-dependent behavior of strtoul().\n\nI think that when a long is 32-bit signed, you will always get 2038 from\nstrtol. There could be systems where that is the case, though, and\ntime_t is of a different size. I'm not sure how much it would be worth\ncaring about them.\n\nOne nice thing about looking for \"if we got 2038, we know we can skip\"\nas opposed to \"did we correctly format this to 2286\" is that we err on\nthe side of failing the test. So if we did ever find such an oddball\nplatform, the test would fail and we could address it then.\n\n> > When the internal time representation is updated from \"unsigned long\" to\n> > a signed and wider type [*1*], test-date has to stop reading the\n> > second-from-epoch input with strtol(),\n> \n> It's strtoul(), actually.\n\nI think both you and Junio are mistaken in the quoted text. :)\n\nThe code in question is in t/helper/test-date.c:show_dates(), and _does_\ncall the signed strtol(). However, it is storing it not in an \"unsigned\nlong\" (which would be utterly silly), but in a time_t.\n\nAnd the value is clamped to LONG_MAX there, so the representation\nelsewhere does not matter at all, as long as it big enough to store\nLONG_MAX. By definition, \"unsigned long\" should be. In practice, I'd\nguess time_t is, though perhaps one could come up with a case of\ncompiling a 64-bit program against a 32-bit ABI? I don't know if that's\npossible.\n\nThat also explains why we get 2038 here, and not our usual sentinel\nvalue of \"(time_t)0\". We _do_ have overflow checks when formatting\npretty-printed dates from commits (see show_ident_date), but the test\nhelper isn't using them.\n\n> Please also note that ULONG_MAX is not required to be either 2^32-1 or\n> 2^64-1. Which means that the 2038 test is really not robust.\n\nOf course not; but as I mentioned above, I think the test can be written\nto complain in the unlikely case that it is not one of those, and we can\ndeal with it then.\n\n> Also note that the 640bit test is very explicit, and hence robust. As a\n> consequence it would skip the absurd dates on systems switching to\n> int128_t for time_t.\n\nActually, I think that is a bad thing. The case that the test in\nquestion was added for was not about overflowing \"unsigned long\", but\nabout having a far-future date that tm_to_time_t() could not handle. And\nthat maxes out at 2100. Testing it on a 128-bit system would be\ncompletely appropriate.\n\n-Peff\n"},{"id":"291408","messageId":"20160714091240.GB26046@glandium.org","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607140952160.6426@virtualbox","subject":"Re: 32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2016-07-14T09:12:40Z","receivedAt":"2016-07-14T09:13:14Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote:\n> Hi Junio,\n> \n> On Wed, 13 Jul 2016, Junio C Hamano wrote:\n> \n> > Does Travis CI testing have an option to run our tests on some\n> > 32-bit platforms?\n> \n> AFAIR Docker does not support 32-bit, and IIRC that's what Travis uses.\n> \n> However, it is possible to install a 32-bit toolchain and use that to\n> compile Git.\n\nYou just need to install gcc-multilib on travis, and you can use -m32. I\ndid that for jemalloc recently.\nSee https://github.com/jemalloc/jemalloc/blob/dev/.travis.yml\n\nMike\n"},{"id":"291409","messageId":"alpine.DEB.2.20.1607141256100.6426@virtualbox","threadId":"42823","inReplyTo":"20160714091240.GB26046@glandium.org","subject":"Re: 32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-14T10:58:47Z","receivedAt":"2016-07-14T10:59:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Mike,\n\nOn Thu, 14 Jul 2016, Mike Hommey wrote:\n\n> On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote:\n> > Hi Junio,\n> > \n> > On Wed, 13 Jul 2016, Junio C Hamano wrote:\n> > \n> > > Does Travis CI testing have an option to run our tests on some\n> > > 32-bit platforms?\n> > \n> > AFAIR Docker does not support 32-bit, and IIRC that's what Travis uses.\n> > \n> > However, it is possible to install a 32-bit toolchain and use that to\n> > compile Git.\n> \n> You just need to install gcc-multilib on travis, and you can use -m32. I\n> did that for jemalloc recently.\n> See https://github.com/jemalloc/jemalloc/blob/dev/.travis.yml\n\nWould we not also need\n\n\tapt:\n\t\tpackages:\n\t\t\tlib32z1\n\n(or ia32libs in case of an older Ubuntu)?\n\nCiao,\nDscho\n"},{"id":"291430","messageId":"alpine.DEB.2.20.1607141804570.6426@virtualbox","threadId":"42823","inReplyTo":"xmqq8tx51hmx.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-14T16:06:53Z","receivedAt":"2016-07-14T16:07:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 13 Jul 2016, Junio C Hamano wrote:\n\n> Moving of [64BIT_TIME] lazy_prereq to test-lib might be an upside if we\n> were planning to add a test that depends on the system having or not\n> having 64-bit timestamp elsewhere, but I do not think of a reason why\n> such a new test cannot go to t0006-date, which has the perfect name for\n> such a test and is not overly long right now (114 lines).\n\nTurns out we *already* have another test in `master` that needs this lazy\nprereq:\n\nhttps://github.com/git/git/blob/79ed43c28f/t/t5000-tar-tree.sh#L378-L384\n\nCiao,\nDscho\n"},{"id":"291500","messageId":"20160715015908.GA15796@glandium.org","threadId":"42823","inReplyTo":"alpine.DEB.2.20.1607141256100.6426@virtualbox","subject":"Re: 32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2016-07-15T01:59:08Z","receivedAt":"2016-07-15T01:59:40Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, Jul 14, 2016 at 12:58:47PM +0200, Johannes Schindelin wrote:\n> Hi Mike,\n> \n> On Thu, 14 Jul 2016, Mike Hommey wrote:\n> \n> > On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote:\n> > > Hi Junio,\n> > > \n> > > On Wed, 13 Jul 2016, Junio C Hamano wrote:\n> > > \n> > > > Does Travis CI testing have an option to run our tests on some\n> > > > 32-bit platforms?\n> > > \n> > > AFAIR Docker does not support 32-bit, and IIRC that's what Travis uses.\n> > > \n> > > However, it is possible to install a 32-bit toolchain and use that to\n> > > compile Git.\n> > \n> > You just need to install gcc-multilib on travis, and you can use -m32. I\n> > did that for jemalloc recently.\n> > See https://github.com/jemalloc/jemalloc/blob/dev/.travis.yml\n> \n> Would we not also need\n> \n> \tapt:\n> \t\tpackages:\n> \t\t\tlib32z1\n> \n> (or ia32libs in case of an older Ubuntu)?\n\nAnd probably some libcurl-something-dev:i386 package too. \n\nMike\n"},{"id":"291586","messageId":"CACsJy8AdsMuFQuej+Z5uePWxq=u8C4dKYZLLMeZNKd8wXesmqg@mail.gmail.com","threadId":"42823","inReplyTo":"F003C6A7-CF52-4149-9A05-8DDA549BABEE@gmail.com","subject":"Re: [ANNOUNCE] Git v2.9.1","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-07-16T05:50:39Z","receivedAt":"2016-07-16T05:51:15Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Jul 14, 2016 at 9:38 AM, Lars Schneider\n wrote:\n>\n> On 13 Jul 2016, at 22:43, Junio C Hamano wrote:\n>\n>> Junio C Hamano writes:\n>>\n>>> It is somewhat disturbing that nobody seems to be regularly building\n>>> on 32-bit platforms these days, which is the only reason I can think\n>>> of why this was never reported until it hit a maintenance track.\n>>> This should have been caught last week at f6a729f3 (Merge branch\n>>> 'jk/tzoffset-fix', 2016-07-06) when the topic hit 'master' at the\n>>> latest, and more preferrably it should have already been caught last\n>>> month at 08ec8c5e (Merge branch 'jk/tzoffset-fix' into next,\n>>> 2016-06-28).\n>>>\n>>> Those who care about 32-bit builds need to start building and\n>>> testing 'next' and 'master' regularly, or similar breakages are\n>>> bound to continue happening X-<.\n>>>\n>>> Volunteers?\n>>\n>> We might eventually see a volunteer or two but that hasn't happened\n>> yet, at least in the past few days.\n>>\n>> Does Travis CI testing have an option to run our tests on some\n>> 32-bit platforms?\n>\n> TravisCI does not support 32-bit platforms natively:\n> https://github.com/travis-ci/travis-ci/issues/986#issuecomment-124141683\n>\n> However, there seems to be a way to enter a 32 bit Trusty chroot on\n> 64 bit Travis via Docker:\n> https://github.com/travis-ci/travis-ci/issues/5770\n>\n> @Duy:\n> You mentioned that you compiled Git on Docker before ($gmane/297963).\n> What do you think the chroot approach? Could that work? Would that\n> be reliable?\n\n\"Docker chroot\" is a weird term because they are not the same. If you\ncan launch a new docker process from travis-ci, I suppose you can use\na docker image with multilib support, then just run 32-bit binaries\nand it should work (unless the host kernel is built to only support\n64-bit).\n-- \nDuy\n"}]}