Agreed. “Clothes make the man” and users + tools make the DVCS. These “network effects” gave us Windows’ dominance and will probably hand git the DVCS crown… git’s kind of a pain to use, but I’m not as dogmatic about DVCSs as I am about programming languages, so I’ll just follow the leader.

Agreed on “forking”, too. It would have been good if another term were used for cloning a repo. “Fork” has a ton of baggage. A “forked” repo is really more like a child of the parent repo: might be very similar to or different than the parent, but is definitely derived from the parent. Maybe “Create Child”? Gitorious uses “clone” (which follows git).

A

On the point of forking however, is it also possible that we’re still not actually forking at all!? It seems to me that a fork in a DVCS is actually closer to a checkout in centralized systems, with the added benefits of full VCS capabilities locally. The term forking appears to be more of a sentimental rebuttal to the popularity of centralized VCS rather than an actual ‘fork’ of a project, even accounting for the greater ease in forking the code base if that was someone’s goal.

My thinking here comes from books like Karl Fogel’s “Producing Open Source Software,” and more specifically the section dedicated to forks in chapter 8 (http://producingoss.com/en/forks.html). Using this definition, while a fork is still technically a checkout of the code base, it has properties closer to a completely separate project without the direct intent of re-merging later on (although there can still be cooperation between them.)

– Lorenz