Earlier quoted context omitted.
The big .git directory is probably binary revisions? Is there any good way around that in git?
I'm a bit confused. Whenever I've used git on my projects, I'd make sure the binaries were excluded, using .gitignore Don't other people do that, too? What's the benefit of having binaries stored? I've never needed that; I've never worked on any huge projects, so I might be missing something crucial.
Facebook's git repo is 54GB
151–160 of 245 posts
Re: Facebook's git repo is 54GB
#152Earlier quoted context omitted.
You can clone with a single revision in git. Still ends up being around 2X the size I believe since you have the objects stored for the single revision as well as the working tree.
2X the size of what? The raw files? Assuming little shared data, sure. But svn will make two copies of every file too.
Re: Facebook's git repo is 54GB
#153Earlier quoted context omitted.
Facebook now has 7000 employees and is 10 years old. Each employee would have had to write 14 kiB of code (357 LOC with 40 (random guess of mine) characters per LOC) every day during this 10 years to produce 8 GiB of code. (Obviously assuming the repository contains only non-compressed code and only one version of everything and no metadata and...)
If they've got memcached with their own patches, linux with their own patches, Hadoop with their own patches, etc. and tons of translations I can see 8 gigs of text.
Re: Facebook's git repo is 54GB
#154Earlier quoted context omitted.
>People change something in their module. They don't test any upstream modules because it's not their problem anymore. If you use any sort of versioning this shouldn't ever cause a problem.
Yeah, doing it this way they can never make API incompatible changes without also fixing everything downstream... which effectively means once a library is popular enough it is locked at it's current API forever.
Re: Facebook's git repo is 54GB
#155The worrying point here is the checkout of 8GB as opposed to the history size itself (46GB). If git is fast enough with SSD, this is hardly anything to worry about. I actually prefer monolithic repos (I realize that the slide posted might be in jest). I have seen projects struggle with submodules and splitting up modules into separate repos. People change something in their module. They don't test any upstream module…
Re: Facebook's git repo is 54GB
#156Earlier quoted context omitted.
>Everyone having access to everything must be worth the security trade-off. I would find this extremely hard to believe, especially at Facebook. At any software company, your code base is what defines you as a company; there is no way they'd let the good stuff sneak out like that.
Lets say you managed to sneak out the code from facebook. You take the logo, draw a red cross over it and scribble "ProAmbook" below. You push it live. Now what? How do you get users? "We are just like facebook - only your friends aren't here" probably wouldn't get users excited. And if you somehow DID manage to get users, don't you think there are "watermarks" in the code, that they could detect and sue you to death…
Re: Facebook's git repo is 54GB
#157Although this is large for a company that deals mostly in web-based projects, it's nothing compared to repository sizes in game development. Usually game assets are in one repository (including compiled binaries) and code in another. The repository containing the game itself can grow to hundreds of gigabytes in size due to tracking revision history on art assets (models, movies, textures, animation data, etc). I woul…
I am working on a game where head is 1TB. On top of code and assets this size includes a few full builds and a full set of game-ready data (the data build process takes something ridiculous like 7 hours, so that's done on a server and it checks the result in). All in the same repository. 1TB is rather a lot. My previous record was 300GB and even that seemed a bit much. But it is very convenient having everything in o…
Re: Facebook's git repo is 54GB
#158Earlier quoted context omitted.
But they surely don't use git for that, right? In scenarios like this a versioning system that does not track all history locally would be a better fit.
It could use git-annex[1]? [1] https://git-annex.branchable.com/
Re: Facebook's git repo is 54GB
#159Earlier quoted context omitted.
Yes, but the new intern would be able to read all the source and "secret sauces". I doubt that an intern on Google would've access to the search codebase. I'd wager that only a handful of trusted employees have access to that codebase.
If you don't trust your employees why did you hire them? Besides, the source code isn't where FB's money is at, that would be their users.
On a small company, I agree. But on FB they're around 5k people. Let's say they have 3k engineers, that's a awful lot of people they're trusting with their source code
Re: Facebook's git repo is 54GB
#160In terms of engineering tradeoffs, this reminds me of a recent talk by Alan Kay where he says that to build the software of the future, you have to pay extra to get the hardware of the future today. [1] Joel Spolsky called it "throwing money at the problem" when, five years ago he got SSD's for everybody at Fog Creek just to deal with a slow build. [2] I don't use Facebook, and I'm not suggesting that they're buildin…