It’s been a while since I made a big blogging change - I’ve been on Wordpress for a pretty long time now and have generally liked it, but the theme wasn’t so hot and the general zeitgiest of my postings have veered much more into programming than politics over the last year or so. So, I thought it might be time for a change.

As of this post, my blogging software of choice is Jekyll and my new hosting provider is GitHub Pages. Which is pretty cool for me, since I am part of the small team here at GitHub.

In the past, I have had two catastrophic data losses from my hosting providers losing a good number of my posts. Each time I thought I would finally remember to setup something that would back them up, but I never did. Now I finally have a secure backup for my blog data, since everything is done via a Git repository. How it works is I keep the source for my blog in a specially named GitHub repository and every time I push to it, GitHub pixies automagically generate my static blog pages for me.

So, now my blog and content are all available via a public Git repository, if you’re interested in using it for anything. I copied the theme and javascript from Michael Bleigh, and you’re welcome to copy it from me, in turn (do remember to credit Michael, though).

I do love GitHub.

At the end of March, I’m going to be traveling to Europe for Scotland on Rails to do a Git talk (also likely a talk at the University of Edinburgh, if you’re there).

While there, I thought I would do a more in-depth training session in London for all our friends toiling in SVN heck or otherwise wanting to sharpen their Git-Fu. My friends at Codebase have helped me rent a space, catering and all that so we can have a nice long session learning the ins and outs of Git.

If you are interested in signing up for the training, which is happening on April 3rd (a Friday), you can check out our website at gitlondon.com. If you know anyone in the UK who might be interested in doing it, please do let them know. If you’re in the UK and don’t want to do the training, but do want to go out for beers after, send me a note.

It seems that a rather popular theme when reading about distributed SCMs on a blog post is that someone says that they hate or love Git, where the hate is generally that it's hard to learn, unintuitive, etc. Then, generally without exception, a mercurial user jumps in on the comments and says something like "I tried Git, but it was impossible to learn, so I'm using Mercurial and it's easy-peasy". That person is wrong.
Git is not hard to learn. At least, not any more difficult than Mercurial is. There, I said it. If you think that Git is like learning Linux - powerful but steep in the curve of learning, while Mercurial is like Mac - more constrained, but far easier to learn, you have either tried the systems a long time ago or have never really tried them and are just repeating the Merc FUD.
Don't get me wrong, it certainly used to be this way. My point here is that if you take a fresh look at the two systems, the majority of beginner to intermediate tasks that you have to do with a DSCM are very similar in both systems and being sufficiently familiar with one takes very little effort to use the other.
I state this because of the incredibly scientific research I concluded tonight, wherein I used hg. I have been a Git guy for several years now and have never previously touched mercurial, and I dove right in a few hours ago and took some notes so I could share what is _not_ intuitive in hg, even from an advanced DSCM user, and to give it a fair shake. Here is what I have concluded:

• Git and Mercurial have nearly the same learning curve
• Some things are easier / more intuitive in Git, and some in Hg
• Both systems have a similar number of overall common commands, of which 90% are identically named
• You can pretty easily move from one to the other for basic tasks

Let me get into a bit of detail about what I found. As my first piece of evidence, I will look at the help menu. If you simply type 'git' or 'hg' on the command line, hg will give you the following 17 commands :

 add        add the specified files on the next commit
 annotate   show changeset information per file line
 clone      make a copy of an existing repository
 commit     commit the specified files or all outstanding changes
 diff       diff repository (or selected files)
 export     dump the header and diffs for one or more changesets
 init       create a new repository in the given directory
 log        show revision history of entire repository or files
 merge      merge working directory with another revision
 parents    show the parents of the working dir or revision
 pull       pull changes from the specified source
 push       push changes to the specified destination
 remove     remove the specified files on the next commit
 serve      export the repository via HTTP
 status     show changed files in the working directory
 update     update working directory

and Git will give you the following 21 commands:

   add        Add file contents to the index
   bisect     Find the change that introduced a bug by binary search
   branch     List, create, or delete branches
   checkout   Checkout a branch or paths to the working tree
   clone      Clone a repository into a new directory
   commit     Record changes to the repository
   diff       Show changes between commits, commit and working tree
   fetch      Download objects and refs from another repository
   grep       Print lines matching a pattern
   init       Create an empty git repository 
   log        Show commit logs
   merge      Join two or more development histories together
   mv         Move or rename a file, a directory, or a symlink
   pull       Fetch from and merge with another repository 
   push       Update remote refs along with associated objects
   rebase     Forward-port local commits to the updated 
   reset      Reset current HEAD to the specified state
   rm         Remove files from the working tree and from index
   show       Show various types of objects
   status     Show the working tree status
   tag        Create, list, delete or verify a tag object 

Take a good look at that, because there is not a lot of frickin' difference. If you know one, you basically know the other. I can attest to that because I didn't need to look up a lot to figure out how to use hg - not because it's so super simple, but because it's nearly identical (for the basic things).
One of the things I hear a lot is that Git has a billion esoteric commands that are cryptic, magical and impossible to remember. That... is true. However, it doesn't matter. What matters are the porcelain commands that are meant to be used by the end user, and there are about 30 of them - the 21 above plus some special stuff like 'stash' and 'submodule'. On the other hand, if you type 'hg help', you get a list of 41 commands.
Now, there are another 100 commands that git will respond to, but they are plumbing commands and are just there in case you want to build something novel - using them is the equivalent of opening up Mercurial and modifying the source. I happen to use a bunch of them to do some really weird stuff that is just not possible in Hg, but there is no reason users even need to know they're there. They are not in the path (as of 1.6) - out of sight, out of mind. As far as a new user is concerned, Git is simpler in it's command set then Hg.
Now, let's look at a simple use of hg - creating a new hg repo and commiting and import:

mkdir test1; cd test1
hg init
cp [files] .
hg add .
hg commit -m 'my message'
hg log

Now, let's look at the same thing in Git:

s/hg/git/g

It's exactly the same thing. clone, add, annotate*, commit, diff, init, log, merge*, pull*, push, rm, status - these are all basically identical in the two systems. (annotate is generally called 'blame' in git, but 'git annotate' will also work, and merge/pull work slightly differently but do largely the same type of thing) This is the core of both systems, these commands are what you spend nearly all of your time doing, and they are almost exactly the same.
Now for the fun part.

Things that are Confusing in Mercurial

I get to listen to Mercs take the high ground all the time about how git is hard to learn and the UI is confusing - now it's my turn. Here are the things I had to go look up because I didn't get it and even the 'hg help' wasn't helping.
You have to set your username via 'vim ~/.hgrc'
In Git, one of the first things you do is :

$ git config --global user.name 'Scott Chacon'
$ git config --global user.email 'schacon@gmail.com'

In Mercurial, far as I can figure, you gotta do that by hand. There is an 'hg showconfig', but no setter (again, far as I can tell). That means you have to look up a snippet of what the actual config format is and paste that into your ~/.hgrc file manually before your commits will stop complaining that no user is set. PITA.
There is no staging area
This is really just a Gitter wondering how Mercs do it, but the lack of a staging area is something I didn't know I would miss. The lack of control over what versions of what files you're committing seems like a huge, huge missing feature to me (again, only because I'm used to Git). People argue that it keeps it simpler, but you can get the equivalent functionality by adding a '-a' to the 'git commit' command every time, which a lot of people do. In my initial foray, that was the only place where Git was actually more complicated than Hg - ignoring the staging functionality takes an extra '-a'.
How do I setup a remote repository?
OK, I have this Hg repository, and I want to create a remote one and push to it. I know I am being an idiot here, but I literally could not figure out how to do this short of doing an 'hg clone ' and looking at the .hg/hgrc file to see what was added to allow 'hg push' to know where to go. I figured out that you could specify it on the command line, but the thought of typing a url every time I want to push made me throw up a little in my mouth. I could not find the equivalent of a 'git remote' where I could add and manipulate my remote repositories without editing the '.hg/hgrc' file. I couldn't find it in the hg book, either. Perhaps in the comments someone could enlighten me.
I setup a repo on BitBucket and the instructions on how to push into it were simply 'clone this', and then I assume you're supposed to pull your files in and then push, but what if you already have a repo? This drove me nuts, and I still don't know how to do it.
Then, for Act II of this little play, I wanted to know how to have another remote - say I want to be able to push my repo to my staging server for deployment and my central server for collaboration. Again, could not figure out how to add it - I ventured a guess and just copied the line in the config file and gave it a different name and that seems to have worked, but do you really have to edit the file to add a remote repository?
It also appears that something that happens incredibly frequently in your typical day is much more complex in Hg than Git - pulling. In Mercurial, you have to do three commands each time you want to pull (and merge) changes from your remote repository:

1  hg pull
2  hg merge
3  hg commit -m 'Merged remote changes'

In Git, that is effectively done with 'git pull'. Now, you can do that with Git:

1  git fetch
2  git merge --no-commit
3  git commit -m 'Merged remote changes'

But WHY? (as an amusing side-note, there is a Merc plugin that adds an 'hg fetch' command that does what 'git pull' does, so in hg: fetch == pull + merge and in git: pull == fetch + merge...)
Branching... poor, poor branching...
I passed out for a quarter second when I read this in the Hg Book:

The easiest way to isolate a “big picture” branch in Mercurial is in a dedicated repository. ... You can then clone a new shared myproject-1.0.1 repository as of that tag.

I was naive enough to think that branches living in entirely different directories was a thing of the past. How SVN of them. I cannot imagine living my life making local clones to effectively deal with long running branches. The book literally says:

"In most instances, isolating branches in repositories is the right approach."

Um, no thank you.
It turns out that the more I get into branching stuff, the more I understand why they advocate that you clone to branch. Everything is on one track - you can't commit something and then easily leave it there for work later and ignore it for the time being, which is what I use branches mainly for. It's like Mercurial is a one-track mixer with some post-it notes to remember where you were and Git is a multi-track board that starts with one and then allows you to snap on new tracks at any time. Not sure if that metaphor worked, but the constraint of not having cheap, real local branches would drive me batty.
When I tried to have two topic branches going at the same time (say a master branch and an experiment branch), it was rather painful. It worked OK until I went back and forth and then when I tried to push it gave me a:

$ hg push
pushing to http://bitbucket.org/Scotty/objective-git/
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)

No! I didn't forget to merge, I want to have two branches! So, I forced it. Then, when I want to switch back to my other branch, it gives me this:

$ hg branch newbranch
abort: a branch of the same name already exists (use --force to override)

Yes, I know it does, I'm switching back to it, you bastard! So, you _can_ have several local branches being developed at the same time, but hg hates it and you cannot push one of them without pushing all of them. It looks like it stores them as sequential changesets but then stores the parents so you can technically recreate the history. However, it seems that you _cannot_ push your A branch without also pushing your B branch.
That. Is. Annoying.
Conclusion
Perhaps some of these things are simpler at first in Hg, but I don't really think they are that much easier (if at all), and the amount of flexibility you lose is so immense that I can't understand how anyone can think of Mercurial as anything other than 'Git Lite'. Same great usability, much less functionality. And if your answer to that is 'get X plugin', then why do you think you're winning the usability battle again?
That's it - I'll keep playing with Hg and sharing my thoughts (being as how they are sooo unbiased). In the meantime, I'll leave you with some more metaphors:
* If DSCMs were bikes, Hg would be the Git bike with the training wheels soldered on.
* If DSCMs were TVs, Git and Hg would turn on to the same channel, but then Git would also have cable.
* If DSCMs were GPS units, both would have places of interest, but Git would also come with the street maps and be able to do driving directions.
* If DSCMs were shoes, you could play basketball in either, but Git would have the pump (for when you needed extra jumping and whatnot)
* If DSCMs were alarm clocks, they would both wake you up, but Git would also make you coffee.
(if you have others, please share - again, the theme is that they're the same out of the box, but then the one is ultimately a lot more useful)

Warning: the following post is a rant - I wrote it so that I could get this frustration off of my chest and out of my mind.
I live in California and I cannot for the bloody life of me understand why there are so many Prop 8 supporters. For those of you that don't know, Proposition 8 is a ballot initiative on the California statewide ballot that will eliminate the rights of gay couples to marry.
How can this be taken as anything other than pure bigotry? It literally makes me sick to my stomach. I have not been so angry at the actions of other people in a long time. I can see a small, zealous minority agitating over this, but there are tons of normal people donating and picketing and arguing for the opportunity to strip rights from those who are not like them. Their self-righteousness, intolerance and in some cases, hatred, are so transparent that I have a hard time understanding how aren't completely mortified at their own blatant vindictiveness.
There is simply no good reason to oppose it. There is no way in which this effects their own lives in any tangible way. It is simply that they don't want people that they don't like in the abstract to be in any way accepted in society. They may as well be wearing t-shirts that say "Gay people are icky, Yes on 8!"
It's that there is actually no argument - the entire 'Yes' campaign is "wink, nod - you know you think it's gross too..."
The sad part is that I actually do understand these people - I know tons of people that will vote 'Yes' on this. It's people who are so ensconced in their own little self-righteous, self-affirming communities that they can justify it internally it as a referendum on gayness without feeling personally guilty. It's naked xenophobia that is still so widely accepted that people don't feel like they're bad people like they would if they were equally blatently racist. Every "argument" for 'Yes' works completely unmodified if you replace 'gay' or 'same-sex' with 'mixed-marriage'.
There are no financial, legal or health implications for anyone who would vote 'Yes'. They just don't want gay people to be able to avoid the social awkwardness that comes with having to refer to your husband as a 'life-partner' instead. They don't want their children to even be exposed to the notion that being gay might be OK - secure in the notion that THEIR children could never be gay. It is that simple. It is not even fundamentally religious - there are churches and synagogues that will marry gay couples, there are tolerant congregations all over the place.
I don't blame the people personally, they're by and large good and loving people, it's the environment - the churches and right-wing agitators that think this crap will energize their base, and people trust them and are moved to action and animosity by them unfairly.
The thing that really bothers me is the support and role of the churches in this. The fact is that this entire thing is fanned and supported by churches across the country. I read that nearly half the funding for the 'Yes' campaign has come from the Mormon church alone, and that this Sunday thousands of pulpits will be used for political purposes to encourage people to vote the "right" way on this - the way Christ would want you to vote.
For some reason, I still naively believe that faith is supposed to be a source of strength - teaching love, understanding and tolerance, not to be a support center for bigotry and judgment. What makes it worse is that I probably know the sections and context of the Bible that most of them draw from as the source of their intolerance and self-righteousness much better than they do, but that wouldn't slow them down one bit. No, they are justified in their judgment - God Himself supports them. I found myself thinking of this quote from Obama's "Audacity of Hope":

"We think of faith as a source of comfort and understanding but find our expressions of faith sowing division; we believe ourselves to be a tolerant people even as racial, religious and cultural tensions roil the landscape."

Sure, in a decade this will all be for naught. The slow movement of tolerance will eventually force peoples view on gay marriage go the route of mixed-marriage bans and segregation - but that we aren't there yet is frustrating to me. That people naturally take such pleasure and zeal in excluding minorities and ostracizing those who are not like them, and furthermore that they are allowed to hide behind religion as a justification for their animosity, makes me truly, truly sad.
Please vote 'No' on 8.