5 ms·

Why's it bad to store source code on Git?

samcasas 12y ago
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
- aeturnum 12y ago
  Funny you should mention Facebook maybe having performance problems with Git: http://git.661346.n2.nabble.com/Git-performance-results-on-a-large-repository-td7250867.html http://git.661346.n2.nabble.com/Git-performance-results-on-a... (2012)
- pionar 12y ago
  This is when a centralized VCS with checkin-checkout concepts really shines. The client only has to check the checked-out files on commit.
- chrismonsanto 12y ago
  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_ 12y ago
    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-calls-td7577352.html http://git.661346.n2.nabble.com/inotify-to-minimize-stat-cal...
- raverbashing 12y ago
  " 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
- patrickg 12y ago
  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).
deleted 12y ago
[deleted]
- ssalenik 12y ago
  git is not a website...
- webvictim 12y ago
  I wouldn't say Facebook and Twitter are competitors. Their models are quite different. - Facebook's complex privacy vs Twitter's binary "public or private" - Facebook's real names vs Twitter's @usernames - Facebook's freeform posting length vs Twitter's 140 character limit
- syntheticnature 12y ago
  They store their code using the Git version-control software, not on Github as you seem to be thinking.

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

aeturnum 12y ago
Funny you should mention Facebook maybe having performance problems with Git: http://git.661346.n2.nabble.com/Git-performance-results-on-a-large-repository-td7250867.html http://git.661346.n2.nabble.com/Git-performance-results-on-a... (2012)
pionar 12y ago
This is when a centralized VCS with checkin-checkout concepts really shines. The client only has to check the checked-out files on commit.
chrismonsanto 12y ago
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_ 12y ago
  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-calls-td7577352.html http://git.661346.n2.nabble.com/inotify-to-minimize-stat-cal...
raverbashing 12y ago
" 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
patrickg 12y ago
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).

deleted 12y ago

[deleted]

ssalenik 12y ago
git is not a website...
webvictim 12y ago
I wouldn't say Facebook and Twitter are competitors. Their models are quite different. - Facebook's complex privacy vs Twitter's binary "public or private" - Facebook's real names vs Twitter's @usernames - Facebook's freeform posting length vs Twitter's 140 character limit
syntheticnature 12y ago
They store their code using the Git version-control software, not on Github as you seem to be thinking.