This can be quite expensive in repositories with many references though: in a real-world repository with around 2.2 million refs, fetching a single commit by its ID takes around 44 seconds.ĭominating the loading time is decompression and parsing of the objects which are referenced by commits. When doing reference negotiation, git-fetch-pack(1) is loading all refs from disk in order to determine which commits it has in common with the remote repository.
(Merged by Junio C Hamano - gitster - in commit 1b2be06, ) fetch-pack: speed up loading of refs via commit graph See commit 3e5e6c6 () by Patrick Steinhardt ( pks-t). With Git 2.34 (Q4 2021), loading of ref tips to prepare for common ancestry negotiation in " git fetch-pack" ( man) has been optimized by taking advantage of the commit graph when available. Not only the protocol v2 will help, but the commit graph ( mentioned here) will help too. Note: I am the only one useing and pushing to this repo. That was a few days ago and the problems I have right now started happeing around that time. When I realized it, I've used git rm to remove them from repository (and ofcourse, git add, git commit and git push to upstream). Recently, I've accidentally added many vendor assets ( bower_components assets) I suspect some recent operations may cause this: On some other machine, when I do git pull origin master it downloads a few MiB of data, and it takes more than 2 minutes to calculate the delta and apply changes. and git commit -m "msg", then git push origin master. I've changed one file (a few lines), then git add. Note I have studied the git-is-very-very-slow question, but in their case the reason was big binary files - while in my repository there is PHP/JS/HTML/CSS only code (no binaries) and the biggest file in the repository is around 800 KB.
0 kommentar(er)
