1) Go is moving from Google Code to Github
2) Go is moving from Mercurial to Git
To echo another user in the thread: "am I the only one who prefers Mercurial to Git?" In my view Mercurial is on par or even superior to Git, but lacks "Linus made it" fame. Too bad... I have used both Mercurial and Git and find hg command line interface much more intuitive to use. As for GUIs, there really isn't much difference between the two (too bad GitHub only supports git though).
I spend most of my life in Git, simply because that's where the market is. I've had people ask me Git questions during interviews, which is mind-boggling, but there you go.
Each time I've worked with Mercurial it's like a giant weight is lifted off of my shoulders. I feel great joy instead of dread each time I have to go look on Stack Overflow for "wait, just what magic flag combination do I need to use to avoid destroying all my work?"
I get the impression that people who prefer Mercurial to Git only ever talk about interfaces and not about the underlying model. It seems to me that especially for a tool as important as version control, the underlying model is significantly more important: you can wrap a mediocre interface in a nice one, but if the model isn't very good you're pretty much stuck. That isn't to say that Mercurial's model is bad per se, but it certainly strikes me as significantly less elegant than Git's. (I'd be happy to find out I'm wrong about this - I know Git's model pretty intimately but am only moderately familiar with Mercurial's.)
This problem seems to generalize quite a bit. Emphasis on surface-level characteristics rather than core differences seems to be prevalent in comparisons of databases, programming languages, web frameworks, etc. This seems quite bad, but I have no idea how to fix it.
> This seems quite bad, but I have no idea how to fix it.
Most people, when interacting with their database, use SQL (or whatever native command language it provides), and don't need to worry about the underpinnings.
Most people, when interacting with their source code repository tool, use the command set provided by the tool and don't worry about the underpinnings.
I've had problems with my databases before that forced me to learn about the horrid can of worms underneath. Until I had these problems, I didn't care because it was entirely irrelevant to the thing I was trying to do.
I've thankfully never had enough of a problem with any of the repo tools I've used (cvs, svn, hg, git) that I needed to go diving into the data structure itself to figure out or fix a problem. I hope I never have to, because that's not the job I'm trying to do.
You shouldn't need to care how the tool works in order to use it, unless using it is your primary job. My primary job is writing code for my application, not writing code for my database or repo tool.
If going distributed, hg provides a much more sane initial set of commands that make more sense to people with experience using anything that isn't git. This matters a lot, because those commands are the only things most users ever really care about.
The underlying model is really not that different. There are some details that give rise to implementation differences, but Git and Mercurial have converged on a very similar approach.
The reason that arguments about Git vs Mercurial tend to focus on the interface is because it's the only thing that's really different. You can do all the same thing with both tools.
There are a couple of actual real differences:
Mercurial's extension capability.
Mercurial's named branch capability.
How important they are is a matter of opinion. I find it interesting that Mercurial was hitorically missing some Git features, but they've all been added as extensions (shipped with the core Mercurial distro generally). That's not really something that's so do-able with Git.
Not sure if it's better or not, but Mercurial has a concept called the RevLog[0]. A basic overview of it is here[1]. It sounds like the revlog format can become corrupted from time-to-time, but it's pretty rare now adays.
hg has a very elegant underlying data model, which you wind up not having to care about at all (a nice property of a good abstraction), unlike git.
:)
I use hg for almost all my own software development, and it's a great pleasure. I've also used hg professionally in both development and support modes, and if/when I ever get around to starting my own software business, hg or other "safe by default" system will be enforced with an iron fist. It's quite a lot better than git.
You're not the only one. If you prefer the Mercurial interface, I highly recommend trying out hg-git. It's an extension that does transparent bi-directional conversion between git and mercurial. I've been using it for the past 3 years to interact with GitHub and colleagues in different companies and I have yet to run into significant problems.
There are some minor nits: occasionally I manually need to forward the "master" tag to the latest revision to push it to git and since git doesn't log file moves you can run into "broken" history for a file, where Mercurial doesn't know a file was moved. But in day-to-day use I don't really have any issues.
