Re: [PATCH v2 0/7] Allow clean/smudge filters to handle huge files in the LLP64 data model

> This patch series came in via the Git for Windows fork
> [https://github.com/git-for-windows/git/pull/3487], and I intend to merge it
> before v2.34.0-rc0, therefore I appreciate every careful review you gentle
> people can spare.
> 
> The x86_64 variant of Windows uses the LLP64 data model, where the long data
> type is 32-bit. This is very different from the LP64 data model used e.g. by
> x86_64 Linux, where unsigned long is 64-bit.
> 
> Most notably, this means that sizeof(unsigned long) != sizeof(size_t) in
> general.
> 
> However, since Git was born in the Linux ecosystem, where that inequality
> does not hold true, it is understandable that unsigned long is used in many
> code locations where size_t should have been used. As a consequence, quite a
> few things are broken e.g. on Windows, when it comes to 4GB file contents or
> larger.
> 
> Using Git LFS [https://git-lfs.github.io/] trying to work around such issues
> is one such a broken scenario. You cannot git checkout, say, 5GB files. Huge
> files will be truncated to whatever the file size is modulo 4GB (in the case
> of a 5GB file, it would be truncated to 1GB).
> 
> This patch series primarily fixes the Git LFS scenario, by allowing clean
> filters to accept 5GB files, and by allowing smudge filters to produce 5GB
> files.
> 
> The much larger project to teach Git to use size_t instead of unsigned long
> in all the appropriate places is hardly scratched by this patch series.
> 
> Side note: The fix for the clean filter included in this series does not
> actually affect Git LFS! The reason is that Git LFS marks its filter as
> required, and therefore Git streams the file contents to Git LFS via a file
> descriptor (which is unaffected by LLP64). A "clean" filter that is not
> marked as required, however, lets Git take the code path that is fixed by
> this patch series.