On Sun, Jun 12, 2011 at 11:33 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Erik Faye-Lund <kusmabite@xxxxxxxxx> writes: > >> On Fri, Jun 10, 2011 at 10:15 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> The size of objects we read from the repository and data we try to put >>> into the repository are represented in "unsigned long", so that on larger >>> architectures we can handle objects that weigh more than 4GB. >> >> shouldn't this be "size_t" instead of "unsigned long"? > > No, this must be unsigned long as that is the internal type we use. I'm not sure I even understand what you mean here. "unsigned long" is the only choice because it's the type we use? That's sounds pretty close to tautology to my ears. Looking a bit more at the code, it seems that we currently use "unsigned long" a lot of places where "size_t" should have been used. And this series is about changing places where "unsigned int" is being used instead of "unsigned long". This sounds backwards to me; shouldn't all code that deals with sizes (both the ones that are "unsigned int" AND the ones that are "unsigned long") be changed to size_t instead? > Implementation of git on 32-bit platforms has always been limited to 4GB > from day one. This topic is not about changing it. As Matthieu pointed out, my comment wasn't about 32-bit systems; "unsigned long" is 32-bit even on 64-bit versions on Windows. I believe TortoiseGit builds Git for Windows as 64-bit, so AFAIK this would still be a problem for them. -- 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