From: Thomas Braun <thomas.braun@virtuell-zuhause.de>
Date: Sat, 18 Mar 2017 13:03:37 GMT
Subject: Re: Commiting files larger than 4 GB on Windows
Message-ID: <1904675654.3064641.1489842217692.JavaMail.open-xchange@app01.ox.hosteurope.de>
In-Reply-To: <2ebd249b-39a4-23c2-13e3-23c91a938313@web.de>

> Torsten Bögershausen <tboegi@web.de> hat am 17. März 2017 um 06:29
> geschrieben:
> 
> 
> On 15/03/17 22:29, Junio C Hamano wrote:
> > Torsten Bögershausen <tboegi@web.de> writes:
> >
> >> The real "show stopper" is at the end.
> >> ...
> >>
> >> ==========================
> >> And it seams as if zlib is the limitation here.
> >> Unless we include the zlib source code into Git and redefine uLong,
> >> is there a nice way around this:
> >> ===========================
> >>
> >>
> >> /usr/include/zconf.h:#  define uLong                 z_uLong
> >> /usr/include/zconf.h:#  define uLongf                z_uLongf
> >> /usr/include/zconf.h:typedef unsigned long  uLong; /* 32 bits or more */
> >> /usr/include/zconf.h:typedef uLong FAR uLongf;
> > Hmph.  Would ef49a7a0 ("zlib: zlib can only process 4GB at a time",
> > 2011-06-10) and e01503b5 ("zlib: allow feeding more than 4GB in one
> > go", 2011-06-10) help us here, though?
> >
> That is good news.
> I tried to replace all "unsigned long" with size_t and got that compiling
> without warnings under Windows 64 bit.
> 
> Compiling this on a 32 bit Linux gave lots of warnings..
> 
> Converting all unsigned long into is probably an overkill.
> Some may stay, some may be converted into off_t, and some size_t.
> 
> Does anybody wants to pick this up?

I'd be interested, altough I can't promise to get it done in the near future.