On 27 May 2009, at 15:01, Tomas Carnecky wrote:
The problem appears to be the different maximum mmap sizes
available on different OSes. Whic I don't really mind the maximum
file size restriction git imposes, this restriction varying from OS
to OS is very annoying, fixing this required rewriting history to
remove the commit, which caused problems as the commit had already
been pulled, and built on, by a number of developers.
If the requirement that all files can be mmapped cannot be easily
removed, would be it perhaps be acceptable to impose a (soft?)
1GB(ish) file size limit? I suggest 1GB as all the OSes I can get
hold of easily (freeBSD, windows, Mac OS X, linux) support a mmap
of size > 1GB.
I think this is a limitation of a 32bit build of git. I just tried
with a 64bit build and it added the file just fine. The compiler on
MacOSX (gcc) produces 32bit builds by default, even if the system
supports 64bit executables. But gcc on 64bit Linux (at least the
installations I have at home) produces a 64bit executables by
default. Solaris/OpenSolaris behaves like MacOSX, no idea about *BSD
or Windows. Maybe this is why git works on Linux but not MacOSX even
on the same hardware.
Btw, I built git with: make install prefix=... CC="gcc -m64", no
modifications needed (MacOSX 10.5.7).
The git installs I am using are all 32bit, this machine doesn't have a
64bit processor (it is one of the few macs released without one). It's
nice to know long term this problem will go away, that all suggests
introducing some limit is not approriate, as while 32bit users have
some arbitary limit above which they cannot go, I am sure all 64-bit
OSes will manage to easily mmap any file. Of course warning such users
they are producing packs that are not going to work on 32bit compiles
of git isn't a stupid idea.
Chris
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html