Конвертация репозитория Mercurial в Git для пользователей Windows

Среди способов конвертации hg репозитория в git наиболее часто рекомендуемый в интернете — использование утилиты fast-export, написанной на python:

Решил им воспользоваться и я. В процессе столкнулся с определёнными сложностями, рецептами устранения которых хотел бы поделиться, т.к. со всеми этими сложностями наверняка столкнутся программисты, работающие в Windows и не пишущие на python.

Создадим hg репозиторий с одним файлом и одним коммитом:

Проведём манипуляции, согласно инструкции выше, но с поправкой на имена репозиториев:

В процессе экспорта на секунду открылось окно консоли git. В результате ничего не конвертировалось. Ок, будем разбираться, что произошло. Запускаем git-bash.exe:

Переходим в папку git-репозитория и пытаемся повторно запустить скрипт:

Ну, конечно же, line 126: python: command not found.

Качаем и устанавливаем python (именно эту версию, т.к. с более новой версией не взлетит): https://www.python.org/ftp/python/2.7.10/python-2.7.10.amd64.msi.

При установке включаем единственную отключенную по-умолчанию опцию — добаление python.exe в path:

Закрываем и открываем git-bash, что бы подтянулись изменения в path, и снова пытаемся выполнить fast-export:

Теперь скрипт заявляет, что не хватает модуля mercurial. Что ж, будем устанавливать. Какой-то не быстрый получается этот быстрый экспорт. Закрываем и открываем powershell консоль, что бы подтянулись изменения в path, и пытаемся установить модуль mercurial:

Pip старый? Что ж, обновим его:

В консоли красным-красно, но pip таки обновился и можно снова попытаться поставить модуль mercurial:

Следует упомянуть, что при установке модуля mercurial, pip может отругаться на отсутствие установленного Microsoft Visual C++ Compiler. На компьютере, где я первоначально возился с конвертацией, так и случилось. Искомый компилятор можно взять тут:

Успех. Возвращаемся к нашему скрипту быстрого экспорта:

Не понравилось ему, как написано имя исходного репозитория. Поправим и запустим заново:

Экспорт прошел, но результат не радует:

• dir показывает, что файлов в папке репозитория нет
• git status говорит, что какой-то файл с непонятным именем был удалён
• git log показывает наличие коммита с нечитаемым комментарием

Тут я сломался и пошел читать исходники скриптов hg-fast-export.sh и hg-fast-export.py. В процессе выяснилось, что у скрипта есть параметр -e, отвечающий за предварительное декодирование имен файлов и комментариев к коммитам перед кодированием в utf-8:

Удалим и создадим заново репозиторий rep.git, а после повторим конвертацию уже с параметром -e cp1251:

Экспорт прошел, результат уже лучше:

• dir по-прежнему показывает, что файлов в папке нет
• git status говорит, что какой-то файл с непонятным именем был удалён
• git log показывает наличие коммита с уже читаемым комментарием
• git reset —hard приводит репозиторий в чувства — файл.txt появляется в директории

Быстрый экспорт можно считать свершившимся.

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.

Converting Mercurial Repositories to Git on Windows

If you work with text, you need version control. That rule applies regardless of whether you write code or poetry (some might argue that those two are the same, anyway). Ignoring the CVS and SVN dinosaurs two distributed version control systems are being regarded as state of the art: Git and Mercurial. Functionality-wise they are nearly identical, but it seems that Git, with its open-source background, is poised to take over the enterprise, too, where Mercurial used to be strongest.

For Starters

If you are just getting started with version control, take a look at the excellent SourceTree client software, and consider one of the popular hosting services Bitbucket, Github or Visual Studio Online, each of which have very usable free plans (although it should be mentioned that Github offers private repositories only for paid accounts).

Conversion

If have have been using version control for some time you might have a number of Mercurial repositories that you want to convert to Git. The remainder of this article explains how to do that on Windows.

This guide assumes you have TortoiseHg and Git installed. When installing Git make sure to select the option Use Git from the Windows Command Prompt as shown in the following screenshot. No other software is required.

Preparation

Edit your mercurial configuration file (located in %Userprofile%\mercurial.ini ), adding the following lines:

This enables the hg-git extension and instructs it to create .git repository directories next to .hg repository directories instead of putting them in subdirectories named git .

On the command line, make sure hg-git is enabled correctly by running:

It should print something like this:

Converting a Mercurial Repository to Git

On the command line, navigate to the mercurial repository you want to convert. This is the directory that contains the .hg subdirectory.

Run the following command to make a bookmark of master for default, so a reference gets created:

Run the following command to create the .git repository directory:

Starting Over

If you made a mistake or forgot something and want to start over simply delete the .git subdirectory and run:

Git: Turning a Bare into a Working Repository

You now have a bare Git repository in addition to the existing Mercurial repository. Turn the bare into a working repository by running:

Create the index (otherwise, Git believes everything has been deleted, since a bare .git repository doesn’t include a file index ):

Your local source directory now contains both a Mercurial and a Git repository:

That is not exactly what they tell you in coding school, but – it works!

You can push the new local Git repository to a remote hosting service like Bitbucket or Visual Studio Online comfortably with Atlassian’s SourceTree client.

You might also want to convert existing .hgignore files to .gitignore files. Unfortunately they are not fully compatible, as .gitignore does not support regular expressions.

Mercurial vs. Git: why Mercurial?

This is a guest blog post by Steve Losh focusing on the primary reasons a team may choose Mercurial as their (distributed) version control system. Check out Steve’s projects to see some of the cool things he has worked on around Distributed Version Control, or jump over to his Bitbucket account and fork one of his many projects.

There are two major distributed version control systems in widespread use today: Mercurial (Hg) and Git. There are many reasons (and opinions) why one would choose Git or Hg, and the next two blog posts in this series aim to explain some of these Whys.

A sane command line interface

The command line interface is the first thing many programmers will see when using a new version control system. Mercurial’s CLI is full-featured, stable, and elegant. It follows the UNIX philosophy: “each command should do one thing and do it well.”

Git’s CLI is designed to be extremely flexible. Each command has many options that can change its behavior. This makes for less typing, but requires you to remember all of the various options and how they interact with each other. Git’s documentation must detail all the interactions between options, which makes it more verbose and difficult to skim.

Mercurial’s simple approach leads to documentation which is sleek and concise. It’s easy to find what you’re looking for — using hg help, so you can spend less time looking at docs and get back to coding. It favors clarity over “cleverness”, which makes for an easier-to-use tool.

Mercurial tries to be helpful by anticipating some of the more common aliases for commands and just making them work. For example, the hg rename command can also be run with hg move or hg mv. Git simply gives you a git mv command. You can create your own git move alias if you like, but that’s yet another step to try to make Git’s CLI pleasant to use while Mercurial’s is pleasant by default.

Mercurial’s CLI is also quite similar to Subversion’s, which can help ease the transition between the two tools. Here’s a comparison of some of the most common commands. Mercurial/Git commands that are the same as their Subversion equivalents are bold.

Subversion (SVN)

Mercurial (Hg)

Git

svn add hg add git add svn blame hg blame git blame svn cat hg cat git show svn checkout hg clone git clone svn commit hg commit ; hg push git commit -a ; git push svn delete/remove hg remove git rm svn diff hg diff git diff, git diff –cached svn help hg help git help svn log hg log git log svn revert hg revert git checkout -f svn status hg status git status svn update hg pull –update git pull svn move/rename hg move/rename git mv

As you can see, Git makes less of an effort to organize its CLI in a way that Subverison users will be used to. While you can work around this by retraining your fingers to type the new commands, it’s yet one more roadblock to switching systems. Worse, it simply isn’t necessary, as Mercurial’s Subversion-user-friendly but still powerful and elegant interface proves.

Safer history with mercurial

Mercurial’s philosophy is that “history is permanent and sacred.” Core Mercurial includes only one single command that can alter history: hg rollback. This command will “undo” the last pull or commit, but will never touch anything further back.

Git, on the other hand, lets you play fast and loose with your project’s history. Commands like git rebase –interactive let you rewrite history, possibly discarding data along the way.

Yes, you can find changesets you’ve destroyed through git rebase –interactive using git reflog, but if it has been more than a month since you made the change, those changesets will be lost (Git will “garbage collect” these changesets after a month).

Including destructive commands in core means new users are more likely to shoot themselves in the foot by running commands with implications they don’t fully understand.

For the times when you do need to rewrite history in Mercurial, you can turn to extensions like collapse, histedit and MQ. Keeping this functionality out of core prevents new users from accidentally using it until they’re ready.

Most of these extensions will also permanently back up any changesets that they destroy into a bundle. These bundles will not be garbage collected, so you don’t have to worry about your version control system eating your data.

GUI support

Many programmers prefer to use a graphical interface to their version control system instead of working through a command line. Several third-party GUIs have been created to make working with Mercurial easier.

One of the tools out there is Sourcetree, a free Git and Mercurial Mac client offered by Atlassian. Sourcetree is an easy-to-use app that connects to many of the popular source code hosting tools out there like Bitbucket, Kiln and (for Git users) GitHub.

TortoiseHg is another available tool — a shell extension for Windows, Linux and OS X that provides a mature, stable GUI to work with Mercurial. Programmers familiar with TortoiseSVN or TortoiseCVS will feel right at home working with TortoiseHg.

If you use the popular Eclipse IDE for your development, there is a plugin called MercurialEclipse that integrates Mercurial into Eclipse, so you never even need to leave your IDE.

Windows support

With Mercurial, Windows support is a first-class feature. The Mercurial crew cares about Windows users and is very concerned with being completely cross-platform. You can build core Mercurial from source on a Windows machine and use it without having to rely on prepackaged binaries if you like.

Git, on the other hand, does not provide support for Windows in its core code. There is a project called msysgit that adds compatibility for Windows. However, it is commonly reported to be slower than Git on Linux, and the fact that it is a completely separate project says something about Git’s attitude toward Windows use.

Backwards compatibility

The maintainer (and original author) of Mercurial, Matt Mackall, is a strong proponent of backwards compatibility, which is important when you’re choosing a version control system that you plan to rely on for a long time.

Easy to extend

Once you get comfortable working with Mercurial, you’ll probably find features that you wish it had. You could talk to the Mercurial developers and try to get someone to implement these features, but that can take a lot of time and effort (and they may decide they don’t want the feature at all).

Mercurial knows that everyone is going to have different needs, so it provides several ways to extend its functionality without changing the core code.

The first method of extending Mercurial is writing shell scripts that call its command line interface. The output of most Mercurial commands is in a “human-readable-but-easy-to-parse” format. It’s often quite simple to write a shell script to do what you need. For example, say you’d like to add a command to automatically paste your current diff to http://dpaste.com. You could write a tiny shell script called “hgpastediff” to do it:

[cc lang=”xml”]
#!/usr/bin/env bash
hg diff | curl -si -F ‘content=

Once that script is on your path you can simply run hgpastediff to paste the code to dpaste, and the location of the paste will be printed for you.

As we mentioned in the last section, Mercurial is committed to maintaining a backwards-compatible command line interface, so you’ll almost never have to worry about your shell scripts breaking when you update to a new version.

Another way to extend Mercurial is to use aliases. Aliases let you define new Mercurial commands that run other commands, possibly with arguments. For example, if you work with someone named Alice and merge with her often, you may find yourself typing hg commit –message “Merge with Alice.” often. You can define an alias in your

/.hgrc file to cut down on this typing:

[cc lang=”xml”]
[alias]
mwa = commit -m “Merge with Alice.”
[/cc]

The 1.7 version of Mercurial included a feature called “shell aliases” that lets you define aliases to run shell commands. We could avoid creating a separate shell script file for our “paste to dpaste” feature by using a shell alias:

[cc lang=”xml”]
[alias]
diffpaste = !hg diff | curl -si -F ‘content=

Shell aliases are a quick and dirty way to make new commands that make your life easier.

Sometimes a shell script is just not powerful enough to add a feature you’d like to see in Mercurial. When that happens, you can write your own Mercurial extension using the extension API. Extensions are written in Python (like Mercurial itself), which is a very common and elegant programming language.

Writing extensions gives you full access to all of Mercurial’s internals, which means you can do just about anything you can imagine.

Commercial support

With a tool as important as a version control system, it’s important to be able to get support when something goes wrong. It’s also helpful to be able to pay for professional training if you don’t have any experienced users in your company already.

There are several places to turn to for Mercurial support and training. The most up-to-date list is the Support page on the Mercurial wiki.

Another place to find information about professional Mercurial consulting is the newly created mercurial-consulting mailing list. If you have specific needs, the mailing list would be the best place to ask.

Hosting tools and services

Programmers almost never work alone, and it’s often beneficial to have a central copy of your repositories that can be browsed easily on the web. There are several ways to make this happen.

The hg serve command fires up a web server on your local computer that other people can view in a browser and pull from. For sharing changes with another person quickly, it couldn’t be easier. For a more secure and permanent server, you’ve got a couple of choices.

Mercurial bundles a repository-serving script similar to hg serve that may fill the needs of smaller companies who just need a way to share links between people. It can run on most servers that support WSGI, and it is included with Mercurial itself.

There are a number of free and paid hosting providers in the market – here are some that Mercurial recommends.

There is also Atlassian’s Fisheye which allows you to browse and search repositories in Git, Mercurial, Subversion, or any of the other supported systems — all configured within a single installation. Fisheye can connect to a Bitbucket repo to give you advanced browsing and search capabilities as well. If you want a bit more out of your code review process, you can tack on the Crucible product to Fisheye as well.

Fisheye connects to popular issue tracking tools like Jira or Bugzilla.

Mercurial or Git?

Now that we have given you a few reasons for Mercurial, you may want to consider using a distributed version control system. In our next blog, we’ll take a look at the advantages of using Git.

Comment and let us know if you chose Mercurial – we would love to hear why and I am sure many readers would as well. If you opted not to use Hg, we’d love to hear why not as well.