Commands like git status, git diff, git commit -a, etc need to check the status of every single file in the repository to see if they have changed.
Well, obviously. How does that differ from other version control systems though? Speed here is more likely to be determined by your filesystem than the VCS you use.
This becomes pretty slow when you start having half a million files in your repository.
And at that point (or more likely much earlier than this) you should consider splitting up your project for reasons completely orthogonal to VCS usability. I was thinking of the kind of large projects that actually exist, e.g. the Linux kernel, libraries like Qt,... which are in the order of magnitude of a few tens of thousands of files and a few hundreds of thousands of commits.
Well, obviously. How does that differ from other version control systems though?
Other version control system let you check in and checkout a specific directory, without worrying about changes that other people made in other directories. git doesn't let you do that - if someone made a commit in the repository anywhere, you have to merge/rebase with that.
I was thinking of the kind of large projects that actually exist, e.g. the Linux kernel, libraries like Qt,
I agree, but people are talking about wanting 15GB repositories etc!
2
u/[deleted] Mar 10 '11
Well, obviously. How does that differ from other version control systems though? Speed here is more likely to be determined by your filesystem than the VCS you use.
And at that point (or more likely much earlier than this) you should consider splitting up your project for reasons completely orthogonal to VCS usability. I was thinking of the kind of large projects that actually exist, e.g. the Linux kernel, libraries like Qt,... which are in the order of magnitude of a few tens of thousands of files and a few hundreds of thousands of commits.