Git – Using Mercurial repository inside a Git one: Feasible? Sane

Case in point: Lets say that you want to change the username on all your previous commits. I've needed to do this several times for various reason.

Git Version

git filter-branch --commit-filter '
        if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
        then
                GIT_COMMITTER_NAME="<New Name>";
                GIT_AUTHOR_NAME="<New Name>";
                GIT_COMMITTER_EMAIL="<New Email>";
                GIT_AUTHOR_EMAIL="<New Email>";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

Mercurial Version:

authors.convert.list file:

<oldname>=<newname>

Command line:

hg convert --authors authors.convert.list SOURCE DEST

Now, which one looks easier to use?

Note: I spent 2 years working solely with Git, so this isn't a "I hate it, I didn't get it in 2 seconds" rant.

For me, it's the usability. Git is very linux oriented with a linux way of doing things. That means command line, man pages, and figuring it out for yourself. It had a very poor GUI (note: I'm basing this off of msysGit from about a year ago), that seemed to just get in my way. I could barely use it

The command line was worse. Being a Linux oriented program, on Windows it was very difficult to use. Instead of a native port they simply wrapped git with MinGW (Think cygwin), which made working with it much more difficult. MinGW isn't Windows Command Prompt, and just acts different. It's crazy that this is the only way to work with Git. Even in Linux it seemed the only way was to work with straight command line. Projects like RabbitVCS helped some, but weren't very powerful.

The command line oriented approach and being a linux program meant that almost all the howto guides, help documentation, and forum/QA questions relied on running monstrous commands like above. The basic SCM commands (commit, pull, push) aren't as complex, but any more and complexity grows exponentially.

I also hate the one place that lots of OSS git users seem to hang around: Github. When you first go to a github page, it slams you with everything you can possibly do. To me, a projects git page looks chaotic, scary, and overly powerful. Even the explanation of what the project is, is pushed down to the bottom. Github really hurts people who don't have a full website already setup. Its issue tracker is also terrible and confusing. Feature overload.

Git users also seemed to be very cult like. Git users seem to always be the ones starting "holy wars" over which DVCS is better, which then forces Mercurial users to defend themselves. Sites like http://whygitisbetterthanx.com/ show arrogance and an almost "Use my software or die" mentality. Many times I've gone into various places of help only to be flamed for not knowing X, using X beforehand, using Windows, etc. It's crazy.

Mercurial on the other hand seems to go towards the kinder approach. Their own home page seems much more friendly to new users than Git's. In a simple Google search the 5th result is TortoiseHg, a very nice GUI for Mercurial. Their entire approach seems to be simplicity first, power later.

With Mercurial I don't have SSH nonsense (SSH is hell on Windows), I don't have stupidly complex commands, I don't have a cult user following, I don't have craziness. Mercurial just works.

TortoiseHg provides an actually usable interface (although lately it seems to be growing) that provides actually useful features. Options are limited to what you need, removing clutter and options that are rarely used. It also provides many decent defaults

Mercurial, being very friendly to new comers, was very easy to pick up. Even some of the more complex topics like the different branching model and history editing were very easy to follow. I picked up Mercurial quickly and painlessly.

Mercurial also just works the first time with little setup. On ANY OS I can just install TortoiseHg and get all the features I want (mainly context menu commands) without having to hunt for different Guis. Also missing is setting up SSH (half of the guides out there say to use Putty, Plink, and Pagent while the other half says to use ssh-keygen). For new users, TortoiseHg takes minutes to setup while Git takes 30 minutes to an hour with lots of googling.

Lastly you have the online repos. Githubs equivalent is BitBucket, which has some of the issues I outlined above. However there's also Google Code. When I go to a Google Code project, I don't get feature overload, I get a nice clean interface. Google Code is more of a online repo/website combo, which really helps OSS projects who don't have an existing site setup. I would feel very comfortable using Google Code as my projects website for quite some time, only building a website when absolutely necessary. Its issue tracker is also powerful, fitting nicely in between Github's almost useless Issue Tracker and Bugzilla's monstrosity.

Mercurial just works, first time, every time. Git gets in my way and only angers me the more I use it.

I've found the hg-git bridge fairly usable going the other direction (exposing some stuff on Github that was originally built using Mercurial for source control). Basically, you "just" use mercurial, create a bookmark linking "master" to the "default" when you're ready to push to a git repo, and push. Pull from git works similarly to the way it does when you pull from a remote repo. You don't end up with .git + .hg files in this scenario, you just have mercurial ones on your local box, unless you end up migrating over to git entirely, in which case you'd probably do git clone in a new directory.

There's a similar project for git users that want to push/pull from Mercurial repositories, but I don't have direct experience with it. See https://github.com/offbytwo/git-hg

Other than the potential of accidentally checking in a bunch of the hidden folders from your "other" source control system, I don't see any real problem with doing hg init in a git repo; it just seems less clunky to me to use a bridge, and explicitly choose when to push to the other dvcs system.