tar xzf foo-1.0.tar.gz
cd foo-1.0
hg init
hg ci -Am 'initial'
cd ..
hg clone foo-1.0 foo-1.0.2

and get the same result.

First and foremost, git does not store or work in terms of patches or diffs. It can certainly output them, but it’s not the way it works internally . There are objects. Objects are a bit like files, only immutable (See also the plan 9 “venti” data store…). They have a “name”, their hash code. Some objects are “commits”, these describe a bunch of objects i.e. a coherent state of the whole tree. The commits are arranged into a coherent timeline as each commit (except the initial commit) has a parent Most objects, however, are just the content of files. There are a few details about tags and branches and merging, but they’re basically just chains of commits.

That’s pretty much it. Everything else is layered on top. Git doesn’t give a crap about neat patch theory or microoptimisation: it just relies on the filesystem underneath being a very high-performance unixoid file system (that’s why git particularly sucks on windows and works well on linux).

Actually, although the theory behind git is straightforward and not too hard to understand, its mapping to real-world use (outside of kernel development) *is* nontrivial and can really hang you up if you don’t think like Linus. If you’re not hardwired for filesystem development, mapping git to your internal notions of changes is quite unnatural.

It lets you check in patches (not whole files) to darcs, mercurial, and cvs. I find it very very useful.

-David

In .hg/hgrc,

[paths]
default=ssh://host/path

But are they just learned notions? I don’t find any of rcs, cvs, svn and darcs more natural than git, any more than windows is more natural than linux (in fact, having learnt linux first, I prefer it). I wouldn’t say I’m “hardwired for filesystem development”.

“its mapping to real-world use (outside of kernel development) *is* nontrivial”

I don’t believe that either. Git is used for a whole bunch of other large projects (mesa and freedesktop.org stuff for starters, but also end-user apps and things like website management
(http://jointheconversation.org/railsgit)),

Do you just mean to “mapping to use like some other RCS instead of git”? But it IS different to other RCSes, I don’t dispute that. That said, there is a darcs interface for git:
http://wiki.darcs.net/DarcsWiki/DarcsGit

• so you get darcs’ interface and git’s engine.

quilt-like functionality for git is provided by stgit. Like cogito, I guess it might get effectively superseded by core git at some stage, but anyway:
http://procode.org/stgit/

When I hear relatively technical people have trouble with Git, yet my CSS guy doesn’t have any problem committing his changes back to the repo, I wonder if people are over thinking it.

The basics of using git unimaginatively are indeed just as easy as CVS or any other RCS. It didn’t used to be so, but it is so now. Using git isn’t hard. Understanding it can be mildly difficult. Bending it to your will (as technical folk are wont to do) requires understanding.

I’m not saying git is rocket science. I’m saying it’s more complicated than hg, with marginal if any benefit.