From: bob Date: Sat, 10 Nov 2007 06:00:27 GMT Subject: Re: git packs Message-ID: In-Reply-To: When you say toolchain, are you referring to the compiler and associated libraries or are you referring to OS programs such as ls, md5, cat, etc or both? The reason that I ask is that I have been playing different scenarios using git 1.5.3.5 under MacOSX 10.4.10 mostly all day and every time that A) a file approaches or exceeds 2gig on an 'add', it results in: fatal: Out of memory? mmap failed: Cannot allocate memory B) the repository size less the .git subdirectory approaches 4gig on a 'fetch' it results in: Resolving 3356 deltas... fatal: serious inflate inconsistency: -3 (unknown compression method) fatal: index-pack died with error code 128 fatal: Fetch failure: ../rmwHtmlOld Under B, building the initial repository works fine. (I added a patch the Linus Torvalds gave out when a previous inflate problem was being researched.) Also, I have been looking in the source in particular in builtin-add.c builtin-pack-objects.c and associated headers and see int and unsigned long being used a lot, but not any unsigned long longs. I have been testing on my laptop which has a 32-bit Intel Core Duo. Also, I have run the same tests on a dual quad-core Intel processor which is 64 bit, (but not sure that Apple uses the 64 bits in 10.4.10). I get the same results as above. The zlib is at the latest revision of 1.2.3 and gcc is at 4.0.1 which from what I can tell supports large files, because 'off_t' is 8 bytes which is the size used for a 'stat' file size. I am just wondering if these size limitations exist for MacOSX or maybe I am doing something wrong (which is probably the case). On Nov 10, 2007, at 12:13 AM, Nicolas Pitre wrote: > On Fri, 9 Nov 2007, bob wrote: > >> When a repository is packed such as for a clone or fetch, is there >> just one >> pack file created that is used for the transfer? > > Yes. > > And modern Git is able to handle packs larger than 4GB too, > assuming it > is compiled using a toolchain with large file support. > > > Nicolas > -