re: the "Impractical for single repository of libraries" section... The author seems to think the only way to manage many different plugins is to split them int

re: the "Impractical for single repository of libraries" section... The author seems to think the only way to manage many different plugins is to split them into different repos: "If you have e.g. 100 plugins, you should have 100 repos." Many times, 1 repo works perfectly fine for 100 plugins. As for wanting to only work with a subset of the files, the way git wants you to do that is to branch and change the subset you want to change (someone else has already pointed that out too here in the comments). What to split into how many repos is often a very subjective call, and depends on team, respository size, and workflow. A real-world example where 1 repo works perfectly fine is the Linux kernel. Within one repo, you have all sorts of drivers for all sorts of hardware, and you have arch-specific support for a dizzying amount of processors and variants. The repo takes a while to clone the first time since it's kind of big, but thereafter works perfectly fine as you whizz between branches and jump between tags. On some level, I understand the author's frustration with git, since it's quite a paradigm shift from centralized repos like Subversion. I made that shift myself once, and at first I didn't like being forced to play by git's rules of the universe (or more correctly, the DVCS rules of the universe). I have come to deeply appreciate those new rules over time. There are, in fact, valid criticisms of git. One that comes to mind is the complexity and amount of operations... looks like others have already commented on this sort of criticism.