Am 15.03.2017 um 14:00 schrieb Florian Adamus:
> Hello,
>
> I am managing my large files with the git-lfs-extension. Some of them
> were more than 4GB in size. After deleting one of those files from my
> working tree and do a normal git checkout I ended up with a somehow
> crippled file with a size of only 46 MB left. For testing reasons I
> tried to commit a 4,3 GB file to my git repository without the LFS
> extension. After checking out a different branch and switching back
> to the branch with the large file, I ended up with the same small
> file as mentioned before. I already wrote a bug issues to Git for
> Windows and I was told that it is a problem with the git source code,
> which uses unsinged long, where it should use size_t. For more
> information on the issue you can check the issue tracker of Git for
> Windows on github. Issue #1063 Is there a way to fix this problem?
Hi,
I can not comment on the git-lfs issues. The issue that you can not properly use files larger than 4GB on windows (no matter if 32bit or 64bit) is known, see my findings from May last year [1]. Unfortunately nobody, including me, did find time to fix the underlying issue properly.
My band-aid patch from [1]
diff --git a/pack-write.c b/pack-write.c
index 33293ce..ebb8b0a 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -313,6 +313,9 @@ int encode_in_pack_object_header(enum object_type type, uintmax_t size, unsigned
if (type < OBJ_COMMIT || type > OBJ_REF_DELTA)
die("bad type %d", type);
+ if (bitsizeof(unsigned long) != bitsizeof(uintmax_t) && size > (unsigned long) size)
+ die("Cannot handle files this big");
+
c = (type << 4) | (size & 15);
size >>= 4;
while (size) {
would at least tell the user much earlier about the problem. I can submit the above diff as proper patch if it is deemed a worthy change.
Thomas
[1]: http://public-inbox.org/git/56EF1402.4050708@xxxxxxxxxxxxxxxxxxx/