-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
git status extremely slow if any 8GBi file is in the repo #3833
Comments
Are you stating that the file length must be exactly 8GBi or 2^33, not one byte more or less? Just wondering if/where the problem roll-over happens. |
I didn't try it to one byte, but the the only files I have trouble with are exactly 2^33. I found it when adding a multi-part zip file with 8GBi file chunks. (I didn't try other multiples of 4GBi either). |
2^33 - 1 bytes works without any issues. |
Did you try 2^33+1 as well? Just wondering if git's squeezing the size value into a 32bit to get funny roll over issues or its the racy problem brian mentioned. |
I have re-confirmed that 2^33 plus or minus 1 byte works. 2^33 does not. The |
hola, necesito de su ayuda, no puedo instalar GIT. cuando termina la instalacion me aparece un cuadro donde dice c:program filesGIT/git-bash.exe |
@florcajal please refrain from adding content to this ticket that is unrelated to the original report. Thank you. @jhattongfs could you re-run with |
I think I got this right. The results are below. git status summary
Full log from git status
|
I went poking through the code and found something that may be helpful. I'm no way qualified to actually attempt to build git though. Please see this and this. It may or may not be helpful. To me, it looks like a file size of 0 does some special stuff, and any file a multiple of 4GBi will trigger this special stuff. I can reproduce this issue on Ubuntu 20.04, git 2.25.1, with or without LFS. |
Oh, that's totally likely the culprit! Because @PhilipOakley started drafting a huge PR to address these type of issues. But that PR only tried to take care of But wait, it gets worse. The Therefore, it will be a huge undertaking to fix this. Lucky for me, this is not a Windows-specific problem! Maybe you therefore want to take it to the Git mailing list (send plain-text messages, HTML messages are dropped silently), @jhattongfs? |
' don't know if this is maybe somehow related, but at our company Largest file I located via this command https://stackoverflow.com/a/46085465/15501748 What caught my attention is that doing a I see the same |
ahh this is probably not related to Nevertheless... the fact remains... the new |
@rpier1 Maybe raise a fresh Issue with all the appropriate template details, including which version was 'previous'. You could try loading the SDK and trying out the different new parts of your git 2.36 (a somewhat directed bisect ;-) to see which aspect is the problem, whether that be the Let's leave this |
@jhattongfs It may be worth taking again to brian @bk2204 as he could advise based on his amending of the entry that follows for the hash algorithm change 575fa8a. A change from The one other thing to be aware of is that CRC32 (was used on earlier proposals) on parts of the Windows ecosystem only covers up to 2GiB block sizes (because it uses long, rather than size_t, for 'history reasons'), should it still be used for the file. |
If this shows up on the Git list, feel free to CC me at the address I normally use there (consult the |
@bk2204 I sent this into the mailing list last night along with my two cents worth. I'm not entirely sure how the list works, but you can search for this exact title "Git status extremely slow if any file is a multiple of 8GBi" on one of the mirrors. I now realize it should have been a multiple of 4GBi, but too late now :/ |
This comment was marked as off-topic.
This comment was marked as off-topic.
I this issue has been resolved upstream and works on git for windows v2.43.0 See commit 5143ac0. |
Setup
64 bit
Windows 10, 64 bit. 21H1
defaults?
to the issue you're seeing?
nope
Details
git bash
Minimal, Complete, and Verifiable example
this will help us understand the issue.
I expected the time to be less than one second.
git commit and all the git status commands take over one minute.
Files that are larger or smaller than 8GB seem to work as expected.
@bk2204 says this is not related to LFS. See 4983.
URL to that repository to help us with testing?
N/A
The text was updated successfully, but these errors were encountered: