[samcasas]

Its not bad, is really nice, but Git has one problem, when you codebase is big, the process takes a long time, imagine git scanning those 8GB every time you do a commit, that is why Facebook was looking to port all their code to another VCS

[chrismonsanto]

I think it's worth making a distinction between the Git plumbing and the Git porcelain when talking about performance. The core functionality (the plumbing) is very fast regardless of repository size. The slowdowns people describe are almost always related to the porcelain commands, which are poorly optimized. Almost every porcelain-level command will cause Git to lstat() every file in your tree, as well as check for the presence of .gitignore files in all of the directories. It's very wasteful.

The fix for this is pretty simple: use filesystem watch hooks like inotify to update an lstat cache. I wrote something like this for an internal project and the speed difference was night and day. I remember reading that there had been progress on the inotify front on the git dev mailing list a few years ago, don't know what the current status is.

[voltagex_]

There was some testing early last year, but I think it's about time for someone to post another reminder

http://git.661346.n2.nabble.com/inotify-to-minimize-stat-cal...

[pionar]

This is when a centralized VCS with checkin-checkout concepts really shines. The client only has to check the checked-out files on commit.

[aeturnum]

Funny you should mention Facebook maybe having performance problems with Git: http://git.661346.n2.nabble.com/Git-performance-results-on-a... (2012)

[patrickg]

I really can't support this claim. I have a repo of 111GB now and it works ok. Not slow at all (unless you do git gc or something like that).

[raverbashing]

" when you codebase is big, the process takes a long time"

From my experience, we can bet git is the one that takes the least amount of time

Not hitting the network to check which files changed, for a start