The largest Git repo

Post by ethomson » Wed, May 24, 2017, 6:52 PM UTC

je42 wrote: post #124

arjie wrote: post #27

Earlier quoted context omitted.

Why split it into separate modules? Seeing that big companies are very successful with monorepos (Google, Facebook, Microsoft), has made me reconsider if repository modularization is actually worth it. There are a host of advantages to not modularizing repos, and I'm beginning to believe they outweigh those of modular repos.

mono repo only works if you have tooling. google's and facebook's tools are not opensource. also, ms tooling is windows only. so for most of us the only reasonable path is to split into multiple repositories. it is also easier to create tools that deal with many repositories. than it is to create a tool that virtualizes a single large repo.

Post by adrianN » Wed, May 24, 2017, 6:55 PM UTC

mdekkers wrote: post #149

lloeki wrote: post #125

Coming from the days of CVS and SVN, git was a freaking miracle in terms of performance, so I have to just put things into perspective here when the topmost issue of git is performance . It's just a testament how huge are the codebases we're dealing with (Windows over there, but also Android, and surely countless others), the staggering amount of code we're wrangling around these days and the level of collaboration i…

I agree. I really think Linux needs a Nobel Price

Post by dullgiulio » Wed, May 24, 2017, 6:58 PM UTC

pvg wrote: post #105

Jyaif wrote: post #51

Earlier quoted context omitted.

pros to big repo: -dont have to spend time to think about defining interfaces cons: -history is full of crap you dont care about -tests take forever to run -tooling breaks down completely, though thanks to MS the limit was increased seriously

-dont have to spend time to think about defining interfaces That seems like a design and policy choice, orthogonal to repos.

Post by Peaker » Wed, May 24, 2017, 6:59 PM UTC

js2 wrote: post #145

Windows, because of the size of the team and the nature of the work, often has VERY large merges across branches (10,000’s of changes with 1,000’s of conflicts). At a former startup, our product was built on Chromium. As the build/release engineer, one of my daily responsibilities was merging Chromium's changes with ours. Just performing the merge and conflict resolution was anywhere from 5 minutes to an hour of my t…

  git-search-replace.py[2] -f oldGlobalName///newGlobalName
  git-mediate -d
  Succcessfully resolved 377 conflicts and failed resolving 1 conflict.
  

Post by vmasto » Wed, May 24, 2017, 7:05 PM UTC

slededit wrote: post #67

saeednoursalehi wrote: post #46

Earlier quoted context omitted.

Indeed, while 19 seconds for commit is far better than 30 minutes we would have seen without GVFS, it's way too slow to actually feel responsive while you're coding. And in fact, it was sometimes worse than 19 seconds because commands like status and add would generally get slower as you access and hydrate more files in the repo. With the big O(modified) update that we just made to GVFS, git commands no longer slow d…

You have to put this into perspective with what they are replacing. You'd never get a submit done in less than 19 seconds using the old source depot tools anyways. When you work on projects this big that takes hours to compile and minutes to incremental compile - responsiveness just isn't something you get to have at scale.