10 ms·

"Git wasn't designed for such vast numbers of developers—more than 20,000 actively working on the codebase. Also, Git wasn't designed for a codebase that was so

"Git wasn't designed for such vast numbers of developers—more than 20,000 actively working on the codebase. Also, Git wasn't designed for a codebase that was so large, either in terms of the number of files and version history for each file, or in terms of sheer size, coming in at more than 300GB. When using standard Git, working with the source repository was unacceptably slow. Common operations (such as checking which files have been modified) would take multiple minutes." These sentences in some parts gloss over the details, and in others it is flat out wrong. Git was designed for tens of thousands of developers (the Linux kernel), it was designed for huge numbers of files (but large numbers of files works fine on Linux due to the dentry cache, it sucks on Windows because they don't have a cache that has the same behaviour as the Linux dentry cache). Admittedly it is slow for files that are large in size, but it was designed for source code; what sane developer would have source files that are hundreds of MB in size? That said, monorepos with several dozen software projects can be very slow due to O(n) functions such as git blame and the like. It's true that git wasn't designed for large numbers of projects in one repo that are only indirectly shared by library code and the like. Unfortunately that was not written in the article.

godzillabrennus 9y ago
Your comment reminds me that Microsoft should really double down on replacing NTFS. Even Apple has moved off HFS+ with their latest OS.
- sekh60 9y ago
  They unfortunately removed the ability to create ReFS disks from Windows 10 Pro and lower. Hopefully they reverse that decision soon. That said I'm not sure how stable it was considered.
alkonaut 9y ago
I develop a desktop app with lots of test documents (test inputs, outputs) that are tied to specific revisions in order to work with the test suite that uses them. None are huge but there are many and some are frequently changed (2GB working copy, 15gb repo, 100k commits). They could be put in some (very) complex hierarchy on a network share, but having them in vcs is so convenient. If rev 9999 changes the code so that the expected output testfileA differs then you update the expected output in the same commit. If you don’t have the file and you want to be able to clone+build+test any revision then you still need the results for 9998 also on the share. This scenario is nicely handled in svn, mercurial, tfvc and similar. If this lets git do it then it looks like a great idea. Game developers with lots of churn in huge binary assets also have the same problem, but probably even worse.
- mkobit 9y ago
  Those kinds of use cases are what Git LFS [1] was created to help with. The major Git vendors support it (Bitbucket, GitHub, GitLab). I'm not as certain about the open source implementations. [1] https://git-lfs.github.com/ https://git-lfs.github.com/
  - alkonaut 9y ago
    I dabbled a bit with lfs but it seems specifically geared towards a few very large resources that you need to manually take care of syncing etc. What we need to move off large repos in tfvc or svn is something where the inconvenience is small enough that it doesn’t weigh heavier than the benefits of git. LFS was not that, this could be.
  - vvanders 9y ago
    Git LFS doesn't solve the gamedev/large asset problem. The issue is that these giant binary files cannot be merged. Because of this you need a locking mechanism(which SVN and Perforce both support). Without that you have two people working on the same file and someone having to throw away work which makes for a very unhappy team. DVCS is great but not every problem domain maps to it.
    - ethomson 9y ago
      git-lfs supports locking, beginning in 2.0.
      - vvanders 9y ago
        Man, had to really dig to find that. Ctrl-F "lock" didn't hit anything on the landing page or main docs page. Even then it looks like an implementation that misses the mark. Both Perforce and SVN mark "lockable" files as Read-Only on a sync of the local copy. It looks like all this does is prevent a push of the file which will be the same result as if someone merged it ahead of you. Without that guard in place it makes it really easy to make a mistake and then have changes to a binary file that will collide. Having a checkout process as part of locking workflow is pretty much mandatory. [edit] Nevermind, I finally found this[1] that explains Git LFS does it correctly, kudos! Could do with some more detailed documentation since it looks partially implemented from the man pages. [1] https://github.com/git-lfs/git-lfs/wiki/File-Locking https://github.com/git-lfs/git-lfs/wiki/File-Locking
Permit 9y ago
>These sentences in some parts gloss over the details, and in others it is flat out wrong. Git was designed for tens of thousands of developers (the Linux kernel), Are there really ten thousand active developers on the Linux Kernel? According to [1] there were ~ 2,000 over a 15 month period. It's an order of magnitude difference that seems like it would have an impact. [1] https://arstechnica.com/information-technology/2015/02/linux-has-2000-new-developers-and-gets-10000-patches-for-each-version/ https://arstechnica.com/information-technology/2015/02/linux...
- deleted 9y ago
  [deleted]
- derefr 9y ago
  And even then, the kernel doesn’t follow anything like the approach to distributed development that your average Github project does. The kernel consists of a bunch of maintainers who each have their own intake branches, to which other people submit PRs or patches as that maintainer wills; and then the mainline kernel, which only takes contributions via patches from one of the maintainers. The nearest thing you could compare the development model to is the set of base packages for the BSDs: each subsystem/package has its own upstream development (like the Linux subsystems with their maintainers); and then Linus serves as the release engineer, taking updates to those packages and merging them into the release. (I compare to the BSDs specifically because Linux kernel subsystems, like non-cross-platform BSD base-system packages, have no other life outside of their potential integration into the release. People aren’t using the upstreams directly, other than in development of the new feature.)
  - stormbrew 9y ago
    I mean, that's the model git was designed for, and it's a model that was designed for a large number of people (by using gatekeepers doing bulk updates to mitigate the flood of small ones). So I don't think raising the way linux uses git by its original intended users really contradicts the idea that it was designed for a large number of developers?
- tedivm 9y ago
marcoperaza 9y ago
The Windows repo is massive, at least 100GB. Consider that the component equivalent to Linux, the NT kernel, is but a small part of the whole thing. And it is indeed a single large project, where every commit has to leave the entirety of Windows in a good state. So if you change some widely used function, you need to fix every single caller in all of Windows. Also, the build system evolves along with the product, so it is checked into the repository as well. The right version of the build system is whatever is in the timestamp you are building. So there’s your seemingly elusive good reason for keeping large binaries in the repo. And while I worked there, the object files from the nightly build were also checked in, so you could rebuild mostly-unchanged components quickly. The alternative to doing it this way is to introduce version management between components, which is totally unnecessary complexity. Windows is one product and all of the components (or subsets thereof) ship together. As far as internal-only interfaces are concerned, version N does not need to work with N-1 or N+1, only N. That is a massively simplifying assumption that makes a lot of things much easier. There is a reason why all the big tech companies operate this way. Microsoft, Google, and Facebook, all have one giant repository with their entire product.
- dingo_bat 9y ago
  > There is a reason why all the big tech companies operate this way. Microsoft, Google, and Facebook, all have one giant repository with their entire product. Cool, but that doesn't explain why Office and Windows need to share the same repo. Ditto for gmail and chrome os. Ditto for fb messenger and whatever face recognition algorithm they use.
  - DaiPlusPlus 9y ago
    Office and Windows don't share the same repo...
  - marcoperaza 9y ago
    I see how my post could have led to that interpretation. That’s not what I meant. There are certainly many many repos in use across Microsoft, for all sorts of different projects. Office doesn’t share the same repo as Windows. And neither does the toolchain (compiler/linker/etc.); only the binaries are checked into the Windows repo. Those are truly separate products, which need to work across different versions of Windows.
jsmthrowaway 9y ago
Tens of thousands of developers pushing changes is not the same as the Linux development process, at all. The key is in the word “actively.” Even Perforce couldn’t keep up with that type of load in a similar situation with Google’s monorepo, forcing them to develop a Perforce-compatible alternative. It’s tough to scale VCS to very large teams, regardless of the software. No need to stand up for git.
perfmode 9y ago
IMHO it is a major failure that git doesn’t scale for org-wide mono repos. Software development process should not be dictated by limitations in the VCS. It surprises me that others are so willing to settle.
- _s 9y ago
  Would you be willing to elaborate on the pros/cons of mono repos vs what git encourages? It seems to just be the wrong fit for a given use case, but works very well others.
  - ed_blackburn 9y ago
    That's a good and valid point, which deserves a conversation undoubtedly - however, there are a lot of businesses out there who have a large monolith, legacy application gigabytes in size where the cost of slicing and dicing into smaller repositories has to be driven by requirements and not technology. My current client has a 17-year-old multi Gb TFS monolith. New components go into git and as features evolve it's common for the respective team to hive them off into they're own git repos as stand-alone components. Nevertheless TFS is painful and if I could have an effective git repo with the monolith too, then life would be far easier.
    - ryanisnan 9y ago
      Is there a way to split a TFS repository, surely you no longer need the past 10 years of commit history on a daily basis - archive it or something? Also how feasible is migrating from TFS to Git?
      - Merad 9y ago
        Very, thanks to git-tfs [1]. My company is in the midst of a move from on premise TFS/TFVC to cloud based VSTS/git. We've run into some projects that managed to somehow mangle their branch history so to the point that we gave up and only migrated the current checkin to git, but most projects pull out the full history and all branches with no trouble. The only real complaint I have is speed. Dunno if it's our TFS server or the nature of TFS, but every checkin pulled into git takes anywhere from 5-30 seconds. In large projects with long histories you can easily spend 30+ minutes exporting history before running into a problem that prevents the export from completing. [1]: https://github.com/git-tfs/git-tfs https://github.com/git-tfs/git-tfs
geofft 9y ago
> in others it is flat out wrong. Git was designed for tens of thousands of developers (the Linux kernel), This is easy to check, and the article is right. The Linux kernel does not have tens of thousands of active developers. Over a little more than the last year: titan:~/src/linux geofft$ git log v4.8..v4.14 --format='%aE' | sort -u | wc -l 4857 If you look at just the most recent release cycle: titan:~/src/linux geofft$ git log v4.13..v4.14 --format='%aE' | sort -u | wc -l 1839 Alternatively, if you look over the last ~year, but at people who have more than five commits (chosen arbitrarily): titan:~/src/linux geofft$ git log v4.8..v4.14 --format='%aE' | sort | uniq -c | awk '$1 > 5' | wc -l 1814 A codebase with 20,000 actively working on the code base is at least an order of magnitude more than the Linux kernel. If they're committing patches every single day, probably more than that. I have, last I checked, four commits in Linux: two for a summer internship in 2009 and two doc fixes. That certainly contributes to the scale of Linux the kernel in the sense of "there are so many people working on it!", but not in the sense of being an "active developer" of the git repo. I was fine sending in my patches to a mailing list and hearing back at some arbitrarily later point, not triggering any CI, not asking anyone else to collaborate on my work, etc. That doesn't work if you have 20,000 engineers on the same codebase writing code every day. > Admittedly it is slow for files that are large in size, but it was designed for source code; what sane developer would have source files that are hundreds of MB in size? Sometimes that's the best way to get things done? The best Debian workflow I've ever worked with (and I've worked with a lot) involved actually committing binary .debs to SVN alongside their source code, because that meant that the SVN revision number was the single source of truth. There wasn't some external artifact system, nor was there a risk of picking up the wrong packages from an apt repo when rebuilding an older SVN revision. I'm not defending this as pretty. But I will defend this as sane. It got the job done reliably and let me work on actually shipping the product and not yak-shaving workflows.
- hitekker 9y ago
  +1 for the research and the distinction between sanity and purity.
- opmac 9y ago
  Good stuff. Came into this thread expecting the top comment to be a know-it-all answer trying to "debunk" the article, as so commonly seen on HN. This is a perfect, well-researched response.
sambf 9y ago
The article was modified to "— more than 3,000 actively working on the codebase".
deleted 9y ago
[deleted]
ethomson 9y ago
I agree that these sentences gloss over the details - and rightly so: it's an article in Ars, after all, not a journal article. We (Microsoft) have published a lot[1] about our journey to put Enterprise-scale codebases, like the Windows codebase, into Git. I think you'll find that they expand upon some of the things that are glossed over. And I would encourage you to read them, so I won't belabor the details here, but to give you just one example: git blame is not the issue that we're most concerned about. The basic, highest priority functionality in Git - things like git add - are the the issues we're most concerned about. git add is O(n) on the number of files in the repository. When you run `add`, git reads the index, modifies the entry (or entries) that you're changing, and writes the index back out. The Windows repository has about 3.5 million files[2]. Running `git add` - when we started thinking about moving Windows into Git - took minutes. Can you imagine running `git add` and having it take 10 minutes? Now obviously there are some inefficiencies here - there's quadratic operations and the like that went in assuming that nobody would ever put 3.5 million files into a Git repository. And we've been cutting those out over time[3]. Thankfully, Git does have some functionality to support very large repositories - using shallow clones, sparse checkouts and the like. We've added narrow clones, to only download portions of the tree, and automation to handle this automatically without user intervention. That's the scaling work that we're doing with GVFS. And these changes bring the P80 time for git add down to 2.5 seconds[4]. We've been contributing these changes back to git itself, and we're thrilled to work with industry partners like GitHub who are also interested. Sorry to go on - version control is a passion of mine, as it is for many of us working on Visual Studio Team Services. Your conclusion is very much correct: Git wasn't designed for this from the beginning. Thankfully, software isn't immutable, so we're scaling it up. [1]: http://gvfs.io/ http://gvfs.io/ [2]: https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/ https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-large... [3]: https://blogs.msdn.microsoft.com/devops/2017/05/30/optimizing-git-beyond-gvfs/ https://blogs.msdn.microsoft.com/devops/2017/05/30/optimizin... [4]: https://blogs.msdn.microsoft.com/devops/2017/11/15/updates-to-gvfs/ https://blogs.msdn.microsoft.com/devops/2017/11/15/updates-t...

godzillabrennus 9y ago

Your comment reminds me that Microsoft should really double down on replacing NTFS. Even Apple has moved off HFS+ with their latest OS.

sekh60 9y ago
They unfortunately removed the ability to create ReFS disks from Windows 10 Pro and lower. Hopefully they reverse that decision soon. That said I'm not sure how stable it was considered.

alkonaut 9y ago

I develop a desktop app with lots of test documents (test inputs, outputs) that are tied to specific revisions in order to work with the test suite that uses them. None are huge but there are many and some are frequently changed (2GB working copy, 15gb repo, 100k commits). They could be put in some (very) complex hierarchy on a network share, but having them in vcs is so convenient. If rev 9999 changes the code so that the expected output testfileA differs then you update the expected output in the same commit. If you don’t have the file and you want to be able to clone+build+test any revision then you still need the results for 9998 also on the share. This scenario is nicely handled in svn, mercurial, tfvc and similar. If this lets git do it then it looks like a great idea. Game developers with lots of churn in huge binary assets also have the same problem, but probably even worse.

mkobit 9y ago
Those kinds of use cases are what Git LFS [1] was created to help with. The major Git vendors support it (Bitbucket, GitHub, GitLab). I'm not as certain about the open source implementations. [1] https://git-lfs.github.com/ https://git-lfs.github.com/
- alkonaut 9y ago
  I dabbled a bit with lfs but it seems specifically geared towards a few very large resources that you need to manually take care of syncing etc. What we need to move off large repos in tfvc or svn is something where the inconvenience is small enough that it doesn’t weigh heavier than the benefits of git. LFS was not that, this could be.
- vvanders 9y ago
  Git LFS doesn't solve the gamedev/large asset problem. The issue is that these giant binary files cannot be merged. Because of this you need a locking mechanism(which SVN and Perforce both support). Without that you have two people working on the same file and someone having to throw away work which makes for a very unhappy team. DVCS is great but not every problem domain maps to it.
  - ethomson 9y ago
    git-lfs supports locking, beginning in 2.0.
    - vvanders 9y ago
      Man, had to really dig to find that. Ctrl-F "lock" didn't hit anything on the landing page or main docs page. Even then it looks like an implementation that misses the mark. Both Perforce and SVN mark "lockable" files as Read-Only on a sync of the local copy. It looks like all this does is prevent a push of the file which will be the same result as if someone merged it ahead of you. Without that guard in place it makes it really easy to make a mistake and then have changes to a binary file that will collide. Having a checkout process as part of locking workflow is pretty much mandatory. [edit] Nevermind, I finally found this[1] that explains Git LFS does it correctly, kudos! Could do with some more detailed documentation since it looks partially implemented from the man pages. [1] https://github.com/git-lfs/git-lfs/wiki/File-Locking https://github.com/git-lfs/git-lfs/wiki/File-Locking

Permit 9y ago

>These sentences in some parts gloss over the details, and in others it is flat out wrong. Git was designed for tens of thousands of developers (the Linux kernel), Are there really ten thousand active developers on the Linux Kernel? According to [1] there were ~ 2,000 over a 15 month period. It's an order of magnitude difference that seems like it would have an impact. [1] https://arstechnica.com/information-technology/2015/02/linux-has-2000-new-developers-and-gets-10000-patches-for-each-version/ https://arstechnica.com/information-technology/2015/02/linux...

deleted 9y ago
[deleted]
derefr 9y ago
And even then, the kernel doesn’t follow anything like the approach to distributed development that your average Github project does. The kernel consists of a bunch of maintainers who each have their own intake branches, to which other people submit PRs or patches as that maintainer wills; and then the mainline kernel, which only takes contributions via patches from one of the maintainers. The nearest thing you could compare the development model to is the set of base packages for the BSDs: each subsystem/package has its own upstream development (like the Linux subsystems with their maintainers); and then Linus serves as the release engineer, taking updates to those packages and merging them into the release. (I compare to the BSDs specifically because Linux kernel subsystems, like non-cross-platform BSD base-system packages, have no other life outside of their potential integration into the release. People aren’t using the upstreams directly, other than in development of the new feature.)
- stormbrew 9y ago
  I mean, that's the model git was designed for, and it's a model that was designed for a large number of people (by using gatekeepers doing bulk updates to mitigate the flood of small ones). So I don't think raising the way linux uses git by its original intended users really contradicts the idea that it was designed for a large number of developers?
tedivm 9y ago

marcoperaza 9y ago

The Windows repo is massive, at least 100GB. Consider that the component equivalent to Linux, the NT kernel, is but a small part of the whole thing. And it is indeed a single large project, where every commit has to leave the entirety of Windows in a good state. So if you change some widely used function, you need to fix every single caller in all of Windows. Also, the build system evolves along with the product, so it is checked into the repository as well. The right version of the build system is whatever is in the timestamp you are building. So there’s your seemingly elusive good reason for keeping large binaries in the repo. And while I worked there, the object files from the nightly build were also checked in, so you could rebuild mostly-unchanged components quickly. The alternative to doing it this way is to introduce version management between components, which is totally unnecessary complexity. Windows is one product and all of the components (or subsets thereof) ship together. As far as internal-only interfaces are concerned, version N does not need to work with N-1 or N+1, only N. That is a massively simplifying assumption that makes a lot of things much easier. There is a reason why all the big tech companies operate this way. Microsoft, Google, and Facebook, all have one giant repository with their entire product.

dingo_bat 9y ago
> There is a reason why all the big tech companies operate this way. Microsoft, Google, and Facebook, all have one giant repository with their entire product. Cool, but that doesn't explain why Office and Windows need to share the same repo. Ditto for gmail and chrome os. Ditto for fb messenger and whatever face recognition algorithm they use.
- DaiPlusPlus 9y ago
  Office and Windows don't share the same repo...
- marcoperaza 9y ago
  I see how my post could have led to that interpretation. That’s not what I meant. There are certainly many many repos in use across Microsoft, for all sorts of different projects. Office doesn’t share the same repo as Windows. And neither does the toolchain (compiler/linker/etc.); only the binaries are checked into the Windows repo. Those are truly separate products, which need to work across different versions of Windows.

jsmthrowaway 9y ago

Tens of thousands of developers pushing changes is not the same as the Linux development process, at all. The key is in the word “actively.” Even Perforce couldn’t keep up with that type of load in a similar situation with Google’s monorepo, forcing them to develop a Perforce-compatible alternative. It’s tough to scale VCS to very large teams, regardless of the software. No need to stand up for git.

perfmode 9y ago

IMHO it is a major failure that git doesn’t scale for org-wide mono repos. Software development process should not be dictated by limitations in the VCS. It surprises me that others are so willing to settle.

_s 9y ago
Would you be willing to elaborate on the pros/cons of mono repos vs what git encourages? It seems to just be the wrong fit for a given use case, but works very well others.
- ed_blackburn 9y ago
  That's a good and valid point, which deserves a conversation undoubtedly - however, there are a lot of businesses out there who have a large monolith, legacy application gigabytes in size where the cost of slicing and dicing into smaller repositories has to be driven by requirements and not technology. My current client has a 17-year-old multi Gb TFS monolith. New components go into git and as features evolve it's common for the respective team to hive them off into they're own git repos as stand-alone components. Nevertheless TFS is painful and if I could have an effective git repo with the monolith too, then life would be far easier.
  - ryanisnan 9y ago
    Is there a way to split a TFS repository, surely you no longer need the past 10 years of commit history on a daily basis - archive it or something? Also how feasible is migrating from TFS to Git?
    - Merad 9y ago
      Very, thanks to git-tfs [1]. My company is in the midst of a move from on premise TFS/TFVC to cloud based VSTS/git. We've run into some projects that managed to somehow mangle their branch history so to the point that we gave up and only migrated the current checkin to git, but most projects pull out the full history and all branches with no trouble. The only real complaint I have is speed. Dunno if it's our TFS server or the nature of TFS, but every checkin pulled into git takes anywhere from 5-30 seconds. In large projects with long histories you can easily spend 30+ minutes exporting history before running into a problem that prevents the export from completing. [1]: https://github.com/git-tfs/git-tfs https://github.com/git-tfs/git-tfs

geofft 9y ago

> in others it is flat out wrong. Git was designed for tens of thousands of developers (the Linux kernel), This is easy to check, and the article is right. The Linux kernel does not have tens of thousands of active developers. Over a little more than the last year: titan:~/src/linux geofft$ git log v4.8..v4.14 --format='%aE' | sort -u | wc -l 4857 If you look at just the most recent release cycle: titan:~/src/linux geofft$ git log v4.13..v4.14 --format='%aE' | sort -u | wc -l 1839 Alternatively, if you look over the last ~year, but at people who have more than five commits (chosen arbitrarily): titan:~/src/linux geofft$ git log v4.8..v4.14 --format='%aE' | sort | uniq -c | awk '$1 > 5' | wc -l 1814 A codebase with 20,000 actively working on the code base is at least an order of magnitude more than the Linux kernel. If they're committing patches every single day, probably more than that. I have, last I checked, four commits in Linux: two for a summer internship in 2009 and two doc fixes. That certainly contributes to the scale of Linux the kernel in the sense of "there are so many people working on it!", but not in the sense of being an "active developer" of the git repo. I was fine sending in my patches to a mailing list and hearing back at some arbitrarily later point, not triggering any CI, not asking anyone else to collaborate on my work, etc. That doesn't work if you have 20,000 engineers on the same codebase writing code every day. > Admittedly it is slow for files that are large in size, but it was designed for source code; what sane developer would have source files that are hundreds of MB in size? Sometimes that's the best way to get things done? The best Debian workflow I've ever worked with (and I've worked with a lot) involved actually committing binary .debs to SVN alongside their source code, because that meant that the SVN revision number was the single source of truth. There wasn't some external artifact system, nor was there a risk of picking up the wrong packages from an apt repo when rebuilding an older SVN revision. I'm not defending this as pretty. But I will defend this as sane. It got the job done reliably and let me work on actually shipping the product and not yak-shaving workflows.

hitekker 9y ago
+1 for the research and the distinction between sanity and purity.
opmac 9y ago
Good stuff. Came into this thread expecting the top comment to be a know-it-all answer trying to "debunk" the article, as so commonly seen on HN. This is a perfect, well-researched response.

sambf 9y ago

The article was modified to "— more than 3,000 actively working on the codebase".

deleted 9y ago

[deleted]

ethomson 9y ago

I agree that these sentences gloss over the details - and rightly so: it's an article in Ars, after all, not a journal article. We (Microsoft) have published a lot[1] about our journey to put Enterprise-scale codebases, like the Windows codebase, into Git. I think you'll find that they expand upon some of the things that are glossed over. And I would encourage you to read them, so I won't belabor the details here, but to give you just one example: git blame is not the issue that we're most concerned about. The basic, highest priority functionality in Git - things like git add - are the the issues we're most concerned about. git add is O(n) on the number of files in the repository. When you run `add`, git reads the index, modifies the entry (or entries) that you're changing, and writes the index back out. The Windows repository has about 3.5 million files[2]. Running `git add` - when we started thinking about moving Windows into Git - took minutes. Can you imagine running `git add` and having it take 10 minutes? Now obviously there are some inefficiencies here - there's quadratic operations and the like that went in assuming that nobody would ever put 3.5 million files into a Git repository. And we've been cutting those out over time[3]. Thankfully, Git does have some functionality to support very large repositories - using shallow clones, sparse checkouts and the like. We've added narrow clones, to only download portions of the tree, and automation to handle this automatically without user intervention. That's the scaling work that we're doing with GVFS. And these changes bring the P80 time for git add down to 2.5 seconds[4]. We've been contributing these changes back to git itself, and we're thrilled to work with industry partners like GitHub who are also interested. Sorry to go on - version control is a passion of mine, as it is for many of us working on Visual Studio Team Services. Your conclusion is very much correct: Git wasn't designed for this from the beginning. Thankfully, software isn't immutable, so we're scaling it up. [1]: http://gvfs.io/ http://gvfs.io/ [2]: https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/ https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-large... [3]: https://blogs.msdn.microsoft.com/devops/2017/05/30/optimizing-git-beyond-gvfs/ https://blogs.msdn.microsoft.com/devops/2017/05/30/optimizin... [4]: https://blogs.msdn.microsoft.com/devops/2017/11/15/updates-to-gvfs/ https://blogs.msdn.microsoft.com/devops/2017/11/15/updates-t...