(Except that I use svn instead of git, but that really doesn't matter).

I'd disagree a little bit with that (in the context of abandoned modules and public repositories (and in general because git and hg are just cooler than SVN, but I digress :)).

If you're using something hosted in SVN you're at the mercy of the repository host, since the project history lives in that one location. If they go walkabout / get hit by a bus / take their ball and go home you lose the project's history unless people have been maintaining their own mirror of the entire repository. Whereas with git (or hg, or any of the new distributed systems) every contributor has the entire history and every repository is just as good as the "master" as soon as you've pulled in any remote changes.

As for making contributing easy, git has a builtin command that bundles up a revision list into ready-to-email patches. There's also a corresponding command for taking an mbox of patches and conditionally pulling them in for the upstream. Or the prospective committer can just put their repo up and say "Hey, I've done X. Look at branch test-X at git://mybox.example.com/snork and see what you think".

There's also a security aspect (not the exact word I'm looking for, but ...) in that it's harder to monkey with project history since revision identifiers are cryptographically determined from change contents (in git and hg it's using cryptographically secure hashes; I believe monotone goes even further in that updates are signed using public keys). Linus alludes to this in his talk at google in that he can lose his entire copy of the kernel source, but if the copy he gets from J. Random Schmuck matches his last good HEAD revision id he knows the contents are the same as what he had to that point.

Did I mention git is just cooler than SVN? :)

PS: Git. Git git git.

Git.

In general I agree that distributed systems are much better than centralized ones.

<rant>

The reason that I don't advocate git usage is that I simply can't work with it.

I tried, a few times already. With different tutorials and with different tasks in mind, and I always failed.

Last time I tried to bisect a regression in perl. There's that cool git-bisect tool which really works great, but it always reported some errors about files that would be overridden with a merge. It took me quite some time that I could work around those with git-clean (no tutorial on git-bisect mentioned that, and I don't think I was doing something unusual).

After I found out, I managed to make a bisect, report the offending changeset to p5p, and rgs answered that it didn't seem to be the right one. D'oh.

I keep hearing good things about git, so I try it out from time to time, but so far it was always disappointing.

Am I too dumb to work with git? Or do the various tutorials suck? or is there some underlying concept that I have to grok, and then all problems turn into a harmless cloud on the distant horizon?

Am I the only one who can't seem to get along with git?

</rant>

It's definitely still "user hostile" software, but I hear anecdotally that recent versions (post 1.4 I believe, post 1.5 even more so) are much improved over even 6 months ago. I've been using it mirroring svn at $work on my desktop to have my own local branches (rather than resorting to svk or kludgy scripts to try and do it correctly in SVN) and I've been very happy with it. I admittedly haven't been using some of the fancier features (like git-bisect), but what I have used works pretty well and when I have hit problems #git on freenode has been very helpful working things out.

I'd also check out Mercurial as well if you haven't, as the feature set's mostly the same as git. I did most of my initial DSCM experimentation with hg and then moved to git with no troubles. (As for why I switched, I just "clicked" better with git than hg when I actually started using it more extensively I think.)

The cake is a lie.
The cake is a lie.
The cake is a lie.

If you're using something hosted in SVN you're at the mercy of the repository host, since the project history lives in that one location. If they go walkabout / get hit by a bus / take their ball and go home you lose the project's history unless people have been maintaining their own mirror of the entire repository. Whereas with git (or hg, or any of the new distributed systems) every contributor has the entire history and every repository is just as good as the "master" as soon as you've pulled in any remote changes.

So that's why people like git :-)

meh.

Do you find Git's long version numbers cumbersome to work with (e.g. compared with the simple numeric version id's used by svn or hg)?

At the moment no. As what I'm mostly using it for at the moment is a local mirror of SVN most of my dealings with them are tangental (e.g. I want to use git-rebase --interactive to squoosh n little changes into one changeset, so I have to read back in the log and just copy the first 8-10 characters and bam I'm done). I imagine if I were interacting with people and maybe verbally referring to them it might be more cumbersome to memorize the hex string vice a 5 digit decimal number, but if most of that kind of interaction were via email I can't see it makes a whole lot of difference (only my paste buffer can tell :).

In a way I like that the revision numbers aren't sequential integers because it helps you (or at least helped me :) break the mental block of a more RCS-y / CVS-y mindset where you have a simple, more linear 1-2-3 chain of revisions and think more along the line of a tree of changes that can be pruned and grafted into whatever order I want. Maybe the lack of sequential-ness does away with the illusion of ordering (another reason I never really liked branching in SVN (aside from the complete lack of builtin memory about where things were merged from) was that it disturbed the continuous sequence of versions illusion the numeric revisions give of (or again, that at least I picked up :)).

Also remember that under the hood Mercurial has the same kind of hash-based revision tokens as git; revision numbers are only valid for one particular instance of a repository. If you need to communicate with anyone who's done independent development their repo's numbers will have diverged and you'll have to use the changeset id anyhow since those do correspond globally.

Update: minor wording tweaks.

The cake is a lie.
The cake is a lie.
The cake is a lie.