Re: [ANNOUNCE] Git v2.9.1

On Thu, Jul 14, 2016 at 9:38 AM, Lars Schneider wrote: > > On 13 Jul 2016, at 22:43, Junio C Hamano wrote: > >> Junio C Hamano writes: >> >>> It is somewhat disturbing that nobody seems to be regularly building >>> on 32-bit

Re: 32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1

On Thu, Jul 14, 2016 at 12:58:47PM +0200, Johannes Schindelin wrote: > Hi Mike, > > On Thu, 14 Jul 2016, Mike Hommey wrote: > > > On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote: > > > Hi Junio, > > > > > > On Wed, 13 Jul 2016, Junio C Hamano wrote: > > > > > > > Does

Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Moving of [64BIT_TIME] lazy_prereq to test-lib might be an upside if we > were planning to add a test that depends on the system having or not > having 64-bit timestamp elsewhere, but I do not think of a reason why > such a new test cannot

Re: 32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1

Hi Mike, On Thu, 14 Jul 2016, Mike Hommey wrote: > On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote: > > Hi Junio, > > > > On Wed, 13 Jul 2016, Junio C Hamano wrote: > > > > > Does Travis CI testing have an option to run our tests on some > > > 32-bit platforms? > > > >

Re: 32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1

On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote: > Hi Junio, > > On Wed, 13 Jul 2016, Junio C Hamano wrote: > > > Does Travis CI testing have an option to run our tests on some > > 32-bit platforms? > > AFAIR Docker does not support 32-bit, and IIRC that's what Travis uses.

Re: [ANNOUNCE] Git v2.9.1

tl;dr I don't really care which fix goes in. They are both fine with me, and in practice I cannot imagine either causing a big problem. But here are my thoughts because I know you want them. On Thu, Jul 14, 2016 at 09:45:12AM +0200, Johannes Schindelin wrote: > > Hmm, sorry, I do not see much

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > So I got curious and looked at the man page. It says indeed that strtoul() > returns ULONG_MAX, which happens to translate into a date in the year > 2038. 4294967295 would rather be 2106. $ date -d @$((0x)) So 7. Feb 07:28:15

32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Does Travis CI testing have an option to run our tests on some > 32-bit platforms? AFAIR Docker does not support 32-bit, and IIRC that's what Travis uses. However, it is possible to install a 32-bit toolchain and use that to compile Git.

Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> I was hoping to hear from you sooner and do v2.9.2 with your t0006 > >> workaround with lazy-prereq changes from Peff (i.e. "Makes sense!" > >> above), so that you do not have

Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > How about this one instead (which is part of the time_t-may-be-int64 > > branch on https://github.com/dscho/git which I still have to complete, as > > some unsigned longs still

Re: [ANNOUNCE] Git v2.9.1

On 13 Jul 2016, at 22:43, Junio C Hamano wrote: > Junio C Hamano writes: > >> It is somewhat disturbing that nobody seems to be regularly building >> on 32-bit platforms these days, which is the only reason I can think >> of why this was never reported

Re: [ANNOUNCE] Git v2.9.1

Junio C Hamano writes: > It is somewhat disturbing that nobody seems to be regularly building > on 32-bit platforms these days, which is the only reason I can think > of why this was never reported until it hit a maintenance track. > This should have been caught last week at

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: >> I was hoping to hear from you sooner and do v2.9.2 with your t0006 >> workaround with lazy-prereq changes from Peff (i.e. "Makes sense!" >> above), so that you do not have to do two releases in a row >> (i.e. skipping v2.9.1 saying "Git

Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > This was just a quick fix, intended to allow me to release Git for Windows > > v2.9.1 in a timely manner (which is now delayed for other reasons). > > ... > >> You'll need to

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > How about this one instead (which is part of the time_t-may-be-int64 > branch on https://github.com/dscho/git which I still have to complete, as > some unsigned longs still slipped out of my previous net)? It strikes me > as much more

Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Tue, 12 Jul 2016, Junio C Hamano wrote: > > > >> Jeff King writes: > >> > >> > In case it wasn't clear, I was mostly guessing there. So I dug a bit > >> >

Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Jeff King writes: > > > Definitely keep that paragraph. I am quite familiar with the test > > helper and it was not the outcome I initially expected. > > > >> +test_lazy_prereq 64BIT_TIME ' > >> + case "$(test-date show:iso

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > On Tue, 12 Jul 2016, Junio C Hamano wrote: > >> Jeff King writes: >> >> > In case it wasn't clear, I was mostly guessing there. So I dug a bit >> > further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t >>

Re: [ANNOUNCE] Git v2.9.1

Jeff King writes: > Definitely keep that paragraph. I am quite familiar with the test > helper and it was not the outcome I initially expected. > >> +test_lazy_prereq 64BIT_TIME ' >> +case "$(test-date show:iso 99)" in >> +*" -> 2038-"*) >> +# on this

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > This was just a quick fix, intended to allow me to release Git for Windows > v2.9.1 in a timely manner (which is now delayed for other reasons). > ... >> You'll need to adjust check_show as I did in my earlier patch. > > Makes sense!

Re: [ANNOUNCE] Git v2.9.1

Hi, On Tue, 12 Jul 2016, Junio C Hamano wrote: > Jeff King writes: > > > In case it wasn't clear, I was mostly guessing there. So I dug a bit > > further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t > > on i386 because of the ABI headaches. > > X-< (yes, I

Re: [ANNOUNCE] Git v2.9.1

Hi Peff, On Tue, 12 Jul 2016, Jeff King wrote: > On Tue, Jul 12, 2016 at 01:25:20PM +0200, Johannes Schindelin wrote: > > > [PATCH] Work around test failures due to timestamps being unsigned long > > > > Git's source code refers to timestamps as unsigned longs. On 32-bit > > platforms, as well

Re: [ANNOUNCE] Git v2.9.1

Hi Duy, On Tue, 12 Jul 2016, Duy Nguyen wrote: > On Tue, Jul 12, 2016 at 3:46 PM, Jeff King wrote: > > On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote: > > > >> Johannes Schindelin writes: > >> > >> > On Tue, 12 Jul 2016, Andreas Schwab

Re: [ANNOUNCE] Git v2.9.1

Hi Andreas, On Tue, 12 Jul 2016, Andreas Schwab wrote: > Johannes Schindelin writes: > > > On Tue, 12 Jul 2016, Andreas Schwab wrote: > > > >> Johannes Schindelin writes: > >> > >> >> PRIuMAX isn't compatible with time_t. > >> > > >> > That

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 11:12:25AM -0700, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> Cool! Thanks for working on this. > > > > Well, I had to. Git for Windows v2.9.1 needs to get released, and I won't > > do that with a failing test suite. > > Let's

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 11:12 AM, Junio C Hamano wrote: > > Let's do 2.9.2 together, as this is not limited to GfW. > > Taking Peff's suggestions into account, perhaps like the attached? If I can get positive comments soon enough, I can do 2.9.2 early tomorrow my time. Or a

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 3:46 PM, Jeff King wrote: > On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote: > >> Johannes Schindelin writes: >> >> > Hi Andreas, >> > >> > On Tue, 12 Jul 2016, Andreas Schwab wrote: >> > >> >> Johannes Schindelin

Re: [ANNOUNCE] Git v2.9.1

Jeff King writes: > In case it wasn't clear, I was mostly guessing there. So I dug a bit > further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t > on i386 because of the ABI headaches. This is being worked on. Andreas. -- Andreas Schwab, sch...@linux-m68k.org

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: >> Cool! Thanks for working on this. > > Well, I had to. Git for Windows v2.9.1 needs to get released, and I won't > do that with a failing test suite. Let's do 2.9.2 together, as this is not limited to GfW. Taking Peff's suggestions into

Re: [ANNOUNCE] Git v2.9.1

Jeff King writes: > In case it wasn't clear, I was mostly guessing there. So I dug a bit > further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t > on i386 because of the ABI headaches. X-< (yes, I knew). > That being said, I still think the "clamp to time_t"

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 08:41:42AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I am not certain that there is a modern system with 32-bit time_t. We > > know there are systems with 32-bit unsigned long, and I think that is > > what produced the results people saw. I'd

Re: [ANNOUNCE] Git v2.9.1

Jeff King writes: > However, I was thinking that it might be handy to have this and some > other information available for helping with debugging. E.g., that we > could ask bug reporters for "git version --build-options" when we > suspect something related to their config. Sure.

Re: [ANNOUNCE] Git v2.9.1

Jeff King writes: > I am not certain that there is a modern system with 32-bit time_t. We > know there are systems with 32-bit unsigned long, and I think that is > what produced the results people saw. I'd expect even 32-bit systems to > use "int64_t" or similar for their time_t

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 08:25:51AM -0700, Junio C Hamano wrote: > On Tue, Jul 12, 2016 at 8:16 AM, Jeff King wrote: > >> > >> But moving the internal time representation used in various fields > >> like commit->date to time_t is likely to be a wrong thing to do, > >> because the

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 8:16 AM, Jeff King wrote: >> >> But moving the internal time representation used in various fields >> like commit->date to time_t is likely to be a wrong thing to do, >> because the first problem with "unsigned long", i.e. "may not be >> wide enough", is not

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 07:34:14AM -0700, Junio C Hamano wrote: > > Git's source code assumes that unsigned long is at least as precise as > > time_t. Well, Git's source code is wrong. > > ... > > That is correct. As people mentioned downthread already, "unsigned > long" has two problems, it

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > Git's source code assumes that unsigned long is at least as precise as > time_t. Well, Git's source code is wrong. > ... That is correct. As people mentioned downthread already, "unsigned long" has two problems, it may not be wide

Re: [ANNOUNCE] Git v2.9.1

On Mon, Jul 11, 2016 at 08:40:56PM -0400, Anders Kaseorg wrote: > On 07/11/2016 07:54 PM, Jeff King wrote: > > Yes, that's somewhat the point of the test. > > > > How does it fail for you (what does it look like with "-v")? We may be > > able to check for an outcome that matches both cases. > >

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 01:25:20PM +0200, Johannes Schindelin wrote: > [PATCH] Work around test failures due to timestamps being unsigned long > > Git's source code refers to timestamps as unsigned longs. On 32-bit > platforms, as well as on Windows, unsigned long is not large enough to >

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote: > Johannes Schindelin writes: > > > Hi Andreas, > > > > On Tue, 12 Jul 2016, Andreas Schwab wrote: > > > >> Johannes Schindelin writes: > >> > >> >> PRIuMAX isn't compatible with

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > Hi Andreas, > > On Tue, 12 Jul 2016, Andreas Schwab wrote: > >> Johannes Schindelin writes: >> >> >> PRIuMAX isn't compatible with time_t. >> > >> > That statement is wrong. >> >> No, it isn't. PRIuMAX is for

Re: [ANNOUNCE] Git v2.9.1

Hi Andreas, On Tue, 12 Jul 2016, Andreas Schwab wrote: > Johannes Schindelin writes: > > >> PRIuMAX isn't compatible with time_t. > > > > That statement is wrong. > > No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t > (even if they happen to have the

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: >> PRIuMAX isn't compatible with time_t. > > That statement is wrong. No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t (even if they happen to have the same representation). Andreas. -- Andreas Schwab, sch...@linux-m68k.org

Re: [ANNOUNCE] Git v2.9.1

Hi Andreas, On Tue, 12 Jul 2016, Andreas Schwab wrote: > Johannes Schindelin writes: > > > @@ -88,11 +88,11 @@ static int local_tzoffset(unsigned long time) > > return offset * eastwest; > > } > > > > -void show_date_relative(unsigned long time, int tz, > >

Re: [ANNOUNCE] Git v2.9.1

Hi Peff, On Tue, 12 Jul 2016, Jeff King wrote: > On Tue, Jul 12, 2016 at 09:30:28AM +0200, Johannes Schindelin wrote: > > > FWIW I have this monster patch as a starting point (I plan to work more on > > this today): > > Cool! Thanks for working on this. Well, I had to. Git for Windows v2.9.1

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > @@ -88,11 +88,11 @@ static int local_tzoffset(unsigned long time) > return offset * eastwest; > } > > -void show_date_relative(unsigned long time, int tz, > +void show_date_relative(time_t time, int tz, >

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 09:30:28AM +0200, Johannes Schindelin wrote: > On Mon, 11 Jul 2016, Junio C Hamano wrote: > > > Those who care about 32-bit builds need to start building and > > testing 'next' and 'master' regularly, or similar breakages are > > bound to continue happening X-<. > >

Re: [ANNOUNCE] Git v2.9.1

Hi Junio & Peff, On Mon, 11 Jul 2016, Junio C Hamano wrote: > Those who care about 32-bit builds need to start building and > testing 'next' and 'master' regularly, or similar breakages are > bound to continue happening X-<. Please note that "unsigned long" is 32-bit even on 64-bit Windows.

Re: [ANNOUNCE] Git v2.9.1

On Mon, Jul 11, 2016 at 06:59:51PM -0700, Junio C Hamano wrote: > > diff --git a/help.c b/help.c > > index 19328ea..0cea240 100644 > > --- a/help.c > > +++ b/help.c > > @@ -419,6 +419,13 @@ int cmd_version(int argc, const char **argv, const > > char *prefix) > > * with external projects

Re: [ANNOUNCE] Git v2.9.1

Jeff King writes: > On Mon, Jul 11, 2016 at 11:35:05PM +0200, Andreas Schwab wrote: > >> Junio C Hamano writes: >> >> > local_tzoffset: detect errors from tm_to_time_t >> >> not ok 19 - show date (iso:5758122296 -0400) >> # >> #

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 12:56:11AM +, Eric Wong wrote: > Jeff King wrote: > > Otherwise, we'll have to skip the test, perhaps with something like the > > patch below. I suspect the problem is actually the size of "unsigned > > long", not time_t, as we use that internally for a

Re: [ANNOUNCE] Git v2.9.1

Jeff King wrote: > Otherwise, we'll have to skip the test, perhaps with something like the > patch below. I suspect the problem is actually the size of "unsigned > long", not time_t, as we use that internally for a bunch of time > computation. We should probably be using int64_t

Re: [ANNOUNCE] Git v2.9.1

On 07/11/2016 07:54 PM, Jeff King wrote: Yes, that's somewhat the point of the test. How does it fail for you (what does it look like with "-v")? We may be able to check for an outcome that matches both cases. On Ubuntu i386 and Ubuntu armhf, I get the following verbose output from

Re: [ANNOUNCE] Git v2.9.1

On Mon, Jul 11, 2016 at 11:35:05PM +0200, Andreas Schwab wrote: > Junio C Hamano writes: > > > local_tzoffset: detect errors from tm_to_time_t > > not ok 19 - show date (iso:5758122296 -0400) > # > # echo "$time -> $expect" >expect && > #

Re: [ANNOUNCE] Git v2.9.1

Junio C Hamano writes: > local_tzoffset: detect errors from tm_to_time_t not ok 19 - show date (iso:5758122296 -0400) # # echo "$time -> $expect" >expect && # test-date show:$format "$time" >actual && #