Does a repository on NFS allow git to run off local disks on each file system?

Question

A local repository is fast only if you have fast access to the data. A repository on NFS is often slower than the repository over SSH on the same server, allowing Git to run off local disks on each system.

Scott Chacon and Ben Straub, Pro Git (New York: Apress, 2014), chap. 4, https://git-scm.com/book/en/v2.

In the second sentence of the quotation above, what allows Git to "run off local disks on each system"? In other words, what is the implicit subject of the -ing participle clause? Is it "A repository on NFS"?

Answer 1

In other words, what is the implicit subject of the -ing participle clause?

(Note: this is more of an English usage question.) I'd say the quoted text is a bit sloppy, grammatically speaking: the subject you're asking about is actually "Git's distributed nature", which appears nowhere in the quoted text.

The distributed nature of Git repositories means that you can clone a repository, copying all the commits¹ from some server version of the repository. Once you have the entire set of commits locally, you can work with those commits, locally, at your local machine's speed. The fact that local drives (often SSDs these days) may be very fast then helps out.

In the 1980s, when NFS was invented, we had slow disk drives (20 millisecond access times were considered fast?). We had SASI and early SCSI drives, holding maybe 100 to 300 MB, spinning at 3600 RPM or slower. Meanwhile, a desktop computer like a Sun 3/50 had a maximum of 4 mega?bytes of RAM (not 4 gigabytes, just 4 MiB). With Ethernet at 10 Mbit/s, reading files over the Ethernet wire was not painfully slow compared to reading files from spinning media, and a big server might have 32 MiB of RAM for caching file data and could use multiple huge 600+ MB drives (e.g., Fuji SuperEagle or bigger). Many 3/50s came "diskless" as a result.

The computing world is, of course, an endless wheel of concept recycling: "cloud storage" is now a big thing. ? The scale goes up—store a few petabytes? no big deal! now if you want a dozen exabytes you're talking real money—but the ideas recur.

---

¹Note that cloning does not copy branch names. That's OK, though, because branch names don't matter: only commits matter. The cloning process takes the server's branch names and transforms them into remote-tracking names—Git calls these remote-tracking branch names, but I find the word branch here has negative value—so that you can find the commits by the server's branch names, using, e.g., origin/feature/tall instead of the branch name feature/tall.

(Your own Git software then uses these remote-tracking names to be able to create your branch names as needed.)