On Monday 11 February 2008 15:28:17 Johannes Schindelin wrote: > Hi, > > On Mon, 11 Feb 2008, Rob Landley wrote: > > I've been using git://git.kernel.dk/data/git/qemu.git although I > > personally prefer mercurial. (It's easier to learn and to use, you get > > the web viewer for free, etc.) > > <rant>I really grow tired of people perpetuating how "easy" Mercurial is, > without substantiating it.
And the macintosh has a nicer desktop than Gnome, too. :P > Granted, git _used_ to be more difficult, but > now? No, really.</rant> I wrote "http://kernel.org/doc/local/git-quick.html", so I'm not speakign entirely from ignorance when I say that Mercurial is way the heck easier to set up and to use. In mercurial, the human readable web repository viewer and the server you pull from are the same thing (and part of the same package). They're different packages in git, set up differently, and live at arbitrarily different URLs such that knowing where to pull from doesn't let you know where a web repository viewer is (or even if there _is_ one, since it's a lot of extra work to set up in git but comes free in mercurial). There's also no mercurial equivalent to the "git update-server-info" comand because it doesn't need one, and if you're behind a firewall that only allows http access you can pull from mercurial but not from git. Also, since the mercurial repository uses apache as its server just use https:// and you get encryption for free, while git has to reimplement all that. You never have to "pack" or "git gc" a mercurial repository. You don't have to install a seperate documentation package in order for "hg help command" to work. The mercurial command syntax doesn't vary wildly depending on which version you have installed, in git it's totally different before 1.5.0 and after... Shall I go on? I dunno an archive for the users at kernel.org mailing list but the vast majority of the traffic is "strange, subtle, and painful things that can go wrong with git". (It's not a high traffic list, but still.) That said, it's the source control system the kernel guys use, and it _is_ the same basic concepts as any other distributed SCM (with a horrible user interface). I don't _object_ to using it, I just don't prefer it. > The biggest obstacle to using a distributed VCS is that many people do not > grasp, and indeed do not even care about, the concept of a distributed > VCS. For me, going from svn to hg was less pain than going from cvs to svn had been. I like mercurial because going "hg log -v", or "hg update -r 12345" is an entirely local operation that doesn't have to go out on the network. I can tell mercurial to spit out a tarball of any arbitrary historical version (or just put it in a directory directly), again without waiting for access to a server and hoping it's up. You get darn spoiled by that, really quick. (And this doesn't even count the maintainer-only stuff like being able to do checkins on plane flights or long car trips. And said checkin taking a fraction of a second to commit, and _never_ having a conflict during the commit stage.) You don't have to worry about new concepts until you want to use branching and merging, which I really don't much. > That's perfectly fine with me, if you don't want to use a distributed > tool, I do not want to force it down your throat. FWIW I am happily using > git on top of CVS, thankyouverymuch. *shrug* Now that the git mirror I use is updating again, I admit my motivation on this topic's dried up a bit. :) > Ciao, > Dscho Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.