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 && #

[ANNOUNCE] Git v2.9.1

The latest maintenance release Git v2.9.1 is now available at the usual places. This release includes fixes to two bugs that have been reported on the list recently, among other changes: - v2.9.0 changed cloning of submodules in a top-level superproject that was cloned shallowly to