I think the author's point is that the git internals (i.e. the .git folder) are simple; I don't think the author is disputing that the commands sitting on top of the git internals are sometimes horribly complicated.
The fact that the contents of the .git folder can be explained in ~2000 words (10 min of reading) is impressive--this would be impossible with a more complicated data model.
> All the results for the svn search are about getting rid of these folders -- nothing explaining their contents.
That would be because there's little to no content in the svn folders, and none of it is user-consumable: all the metadata manipulation is done via svn's properties[0] and their cli interface (proplist, propset, propget and propdel).
Apart from these, the content of the .svn folders (at least before 1.5) is pretty much only duplicates of your checked-out files. All the brains live in the (remote) repository, not in the .svn folders. I've never seen any case where somebody would go muck around with the content of the .svn repos, the only direct manipulation of them users have a use for is stripping them for exports or because somebody did not `svn export` and sent .svn folders where they did not belong.
Oh, and svn has had a full-featured client library[1] (and bindings for most popular languages[2]) for a very long time, so people have rarely needed to essentially reverse-engineer the interaction process from a checked-out working copy.
edit: now that I think about it further, your very observation is proving the complexity of git, or at least of git's UI: it's not expected that users of svn ever go muck around with their .svn (and as I explained there really is no reason to), so there is no wondering or audience about that, whereas not only is it expected that git users understand the content of their .git, it's pretty likely it will become necessary at one point in your usage of git, because you'll have no other way (learning the plumbing by rote is not an option until you've even done that, since it can only be understood if you know how git's store works, you'll just end up learning both anyway)
A better comparison would be between an explanation of the contents of .git and the contents of your actual SVN repo on the server. Since that's what the equivalency is.
Comments
I think the author's point is that the git internals (i.e. the .git folder) are simple; I don't think the author is disputing that the commands sitting on top of the git internals are sometimes horribly complicated.
The fact that the contents of the .git folder can be explained in ~2000 words (10 min of reading) is impressive--this would be impossible with a more complicated data model.
FWIW, compare:
http://www.google.com/search?q=what%20is%20in%20.svn%20folde...?
with
http://www.google.com/search?q=what%20is%20in%20.git%20folde...?
All the results for the svn search are about getting rid of these folders -- nothing explaining their contents.
> All the results for the svn search are about getting rid of these folders -- nothing explaining their contents.
That would be because there's little to no content in the svn folders, and none of it is user-consumable: all the metadata manipulation is done via svn's properties[0] and their cli interface (proplist, propset, propget and propdel).
Apart from these, the content of the .svn folders (at least before 1.5) is pretty much only duplicates of your checked-out files. All the brains live in the (remote) repository, not in the .svn folders. I've never seen any case where somebody would go muck around with the content of the .svn repos, the only direct manipulation of them users have a use for is stripping them for exports or because somebody did not `svn export` and sent .svn folders where they did not belong.
Oh, and svn has had a full-featured client library[1] (and bindings for most popular languages[2]) for a very long time, so people have rarely needed to essentially reverse-engineer the interaction process from a checked-out working copy.
edit: now that I think about it further, your very observation is proving the complexity of git, or at least of git's UI: it's not expected that users of svn ever go muck around with their .svn (and as I explained there really is no reason to), so there is no wondering or audience about that, whereas not only is it expected that git users understand the content of their .git, it's pretty likely it will become necessary at one point in your usage of git, because you'll have no other way (learning the plumbing by rote is not an option until you've even done that, since it can only be understood if you know how git's store works, you'll just end up learning both anyway)
[0] http://svnbook.red-bean.com/en/1.1/ch07s02.html
[1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/
[2] http://svn.apache.org/repos/asf/subversion/trunk/subversion/...
A better comparison would be between an explanation of the contents of .git and the contents of your actual SVN repo on the server. Since that's what the equivalency is.
My point is that to a naive user googling to figure out what is going on, the dotfile element of svn is inscrutable.