Does anyone know what are the Git limits for number of files and size of files?
This question is related to
This message from Linus himself can help you with some other limits
[...] CVS, ie it really ends up being pretty much oriented to a "one file at a time" model.
Which is nice in that you can have a million files, and then only check out a few of them - you'll never even see the impact of the other 999,995 files.
Git fundamentally never really looks at less than the whole repo. Even if you limit things a bit (ie check out just a portion, or have the history go back just a bit), git ends up still always caring about the whole thing, and carrying the knowledge around.
So git scales really badly if you force it to look at everything as one huge repository. I don't think that part is really fixable, although we can probably improve on it.
And yes, then there's the "big file" issues. I really don't know what to do about huge files. We suck at them, I know.
See more in my other answer: the limit with Git is that each repository must represent a "coherent set of files", the "all system" in itself (you can not tag "part of a repository").
If your system is made of autonomous (but inter-dependent) parts, you must use submodules.
As illustrated by Talljoe's answer, the limit can be a system one (large number of files), but if you do understand the nature of Git (about data coherency represented by its SHA-1 keys), you will realize the true "limit" is a usage one: i.e, you should not try to store everything in a Git repository, unless you are prepared to always get or tag everything back. For some large projects, it would make no sense.
For a more in-depth look at git limits, see "git with large files"
(which mentions git-lfs: a solution to store large files outside the git repo. GitHub, April 2015)
The three issues that limits a git repo:
A more recent thread (Feb. 2015) illustrates the limiting factors for a Git repo:
Will a few simultaneous clones from the central server also slow down other concurrent operations for other users?
There are no locks in server when cloning, so in theory cloning does not affect other operations. Cloning can use lots of memory though (and a lot of cpu unless you turn on reachability bitmap feature, which you should).
git pull' be slow?
If we exclude the server side, the size of your tree is the main factor, but your 25k files should be fine (linux has 48k files).
This one is not affected by how deep your repo's history is, or how wide your tree is, so should be quick..
Ah the number of refs may affect both
I think Stefan knows better than I in this area.
git commit'? (It is listed as slow in reference 3.) '
git status'? (Slow again in reference 3 though I don't see it.)
Again, the size of your tree. At your repo's size, I don't think you need to worry about it.
Some operations might not seem to be day-to-day but if they are called frequently by the web front-end to GitLab/Stash/GitHub etc then they can become bottlenecks. (e.g. '
git branch --contains' seems terribly adversely affected by large numbers of branches.)
git-blamecould be slow when a file is modified a lot.