> Am I correct in that the work to make mainline Git use size_t where applicable is ongoing?
It's currently a little stalled, because it's been hard to partition the problem into small chunks that fit everyone's expectations about what should be in or out for tidying up consequences (e.g. large call chains). It's not really clear if "size_t" is considered a nice data type, along with `ssize_t` to be replacing `ulong` and `long`, as they tend to make the code feel "ugly". On Thursday, March 3, 2022 at 1:44:19 PM UTC Konstantin Khomoutov wrote: > On Thu, Mar 03, 2022 at 03:03:34AM -0800, Philip Oakley wrote: > > >> By the way, do you use a 64-bit install? If, for some reason, you're > using > >> a 32-bit version, the limit of circa 4 GB (actaually lower) will be > >> "native". > > > > The Git code is merely POSIX compliant (long == size_t; LP64), while Git > > for Windows uses LLP64 (long=32bits; long long == size_t). > > Vast swathe's of the Git code use long and size_t interchangeably, > meaning > > that GfW is limited, in the main, to 4GB file sizes and 2GB if (signed) > int > > is used. The Git LFS implementation part has been fixed, as long as the > >2GB > > files are stored in LFS, which does handle the large files. However > > that isn't pure Git, so hash oids change, etc. > > > > Hope that clarifies. > > Thanks! > > Am I correct in that the work to make mainline Git use size_t where > applicable > is ongoing? > > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/76c52864-b8f9-43ef-9f66-bf7f5edc2830n%40googlegroups.com.
