I don't actually remember making that argument. But I will try to reconstruct my thinking... (1) Keeping an entire repo in a single file is a better abstracti

I don't actually remember making that argument. But I will try to reconstruct my thinking... (1) Keeping an entire repo in a single file is a better abstraction. There is just one file to move around or rename. There is a single icon on your desktop to drag around or double-click on. There is a single file to attach to an email. There is a single file to measure the size of when judging the size of a repository. And so forth. Lots of programs bundle multiple entities into a single file for convenience like this. For example, a DOCX file is really a ZIP archive containing lots of individual pieces. Would you rather your document be a single DOCX file, or a directory full of the individual pieces. Which would be more convenient to use, do you suppose? How is a VCS repository different from a DOCX file in this respect? Another way to look at this: Breaking up a repository into a directory full of separate files exposes internal implementation details to the user. (2) Perhaps I was making the argument that a relational database is better than a key/value database for holding a repository. (A directory full of files is just a kind of key/value database after all.) There are countless reasons why relational databases work better than key/value databases. One example: With Git, given an individual check-in, it is difficult to discover the descendants of that check-in. It is so difficult, in fact, that none of the common Git tools provide that capability, and Git workflows are engineered (perhaps subconsciously) to avoid the need to ever figure out what comes after a specific check-in. But if Git used a relational database to store content, finding the descendants of a check-in would be a fast and simple query. (3) I/O to a single relational database is faster than I/O to individual files on disk. See https://www.sqlite.org/fasterthanfs.html https://www.sqlite.org/fasterthanfs.html for details.