From: Thomas Braun <thomas.braun@virtuell-zuhause.de>
To: Florian Adamus <florian-adamus@gmx.de>, git@vger.kernel.org
Subject: Re: Commiting files larger than 4 GB on Windows
Date: Wed, 15 Mar 2017 14:48:57 +0100 [thread overview]
Message-ID: <179b5d92-ee96-c2df-dbd8-eb96f7bbdb24@virtuell-zuhause.de> (raw)
In-Reply-To: <trinity-9f703269-6f73-4f6d-b90b-45e09e1c094c-1489582854278@3capp-gmx-bs66>
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@virtuell-zuhause.de/
next prev parent reply other threads:[~2017-03-15 13:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 13:00 Commiting files larger than 4 GB on Windows Florian Adamus
2017-03-15 13:48 ` Thomas Braun [this message]
2017-03-15 15:59 ` Jeff King
2017-03-15 16:13 ` Jeff King
2017-03-15 18:23 ` Thomas Braun
2017-03-15 21:15 ` Torsten Bögershausen
2017-03-15 21:29 ` Junio C Hamano
2017-03-17 5:29 ` Torsten Bögershausen
2017-03-18 13:03 ` Thomas Braun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=179b5d92-ee96-c2df-dbd8-eb96f7bbdb24@virtuell-zuhause.de \
--to=thomas.braun@virtuell-zuhause.de \
--cc=florian-adamus@gmx.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).