solovyov.net

Mercurial vs git

5 min read · vcs, nix, hg, git

Я уже довольно давно собираюсь написать хоть какое-то примерное сравнение этих двух систем контроля версий - просто потому, что меня это касается довольно прямым образом. Но постоянно не мог собраться - сомнения, как бы начать, достаточно ли я для себя точек сравнения накопил, и так далее… В конце концов решил не тянуть резину в долгий ящик и написать то, что есть. Возможно, если получится мало и спорно, в жарких дискуссиях начнёт просыпаться истина… эээ… это я как-то отвлёкся от темы, приступим к делу. :-)

Итак - два участника. Git - более гиковский (в представлении его создателей и фанов ;), и Mercurial - написанный на питоне. Аргументы абсолютно ортогональные друг другу, но дело в том, что я всегда тяготел к более гиковским программам - однако логично, что я сейчас тяготею к программам, написанным на питоне. :-) Однако оказалось, что гиковость выразилась в довольно неожиданном (как для меня) виде - абсолютно не в виде нестандартного, более мощного, интерфейса, а в виде… Удачное высказывание - грех не процитировать:

dottedmag: UI неконсистентен совсем

Абсолютно неконсистентен. Можно плюнуть на 146 (!) файлов в /usr/bin (из которых больше ста - компилированные бинарники): они, типа, соответствуют никсовой философии “одна утилита для одной задачи” (на мой взгляд, git в общем выполняет очень даже одну задачу - хранение версий моих данных) - это, кстати, собираются вроде в скором будущем поправить. Но самый простой пример - выбивает из колеи. Для меня являлось нормальным создавать клон репозитория удалённо простой командой:

hg clone byteflow ssh://piranha@piranha.org.ua/dev/byteflow

Репозиторий клонирован. Я могу, опять же по ssh, забрать его. Могу настроить web-доступ для него (опять же, если я настроил весь ~/dev/ показывать в веб-морде, и без этого можно обойтись). В git’e… читаем хелп:

<repository>
The (possibly remote) repository to clone from. See the URLS section below for more information on specifying repositories.
<directory>
The name of a new directory to clone into.

Это мелочь. Я могу поставить sshfs (ха, если я не в винде сижу!), и склонировать как будто бы в локальную директорию. Но эти мелочи идут сквозняком через весь интерфейс git’а, что приводит к значительно более раздражающей меня проблеме - адресам у веб-интерфейса. Достаточно сравнить:

Из обоих убраны идентификаторы ревизии (заменены на символические аналоги последней ревизии - HEAD и tip). Что легче прочитать? Запомнить? Я очень часто набираю ссылки по памяти, но с git’ом этот фокус провернуть на порядки сложнее.

Ещё одна проблема с адресами - у меркуриала один и тот же адрес является адресом веб-интерфейса и адресом для самого клиента меркуриала: надо помнить лишь один адрес. С гитом этот номер не прокатит - попробуй догадайся про адрес у первого репозитория без подсказки? Тут повезло, всего лишь git://git.catap.ru/emacs-jabber. Но… интерфейс, это интерфейс…

И для этого адреса приходится держать отдельный демон. Который, само собой, о виртуальных хостах не знает ничего, которые сами собой разумеются при работе с веб-мордой меркуриала.

Продвигаемся вперёд по плану гнобления1: набор команд. Не видел ни разу человека, набиравшего команду status полностью - все пишут st. Обломитесь

А что мы можем сказать о помощи? У систем огромное количество команд и возможностей. Помощь в меркуриале - это информация по сути дела. hg help clone - одна страница с описанием поведения при разных условиях и списком специфических опций. git help clone - 4 страницы текста. Зачем мне столько? Я хочу краткий хелп, а не руководство. Руководство должно быть в man-pages или в виде книжки. Когда у меня есть только медленная консоль, это не может не раздражать.

На этом претензии, накопленные не к фичам гита, у меня пока исчёрпываются - можно лишь благодарить богов, что мне не приходится это чудо использовать так же много, как и меркуриал. К фичам придраться тоже можно было бы, но этого и так хватает в интернетах - к примеру, отсутствие удобного аналога mq.

К завершению подойду полупинком (почему “полу” - об этом позже) в сторону меркуриала. В гите есть довольно удобная штука в виде бранчей. Это что-то типа внутрирепозиторийных клонов (можно провести прямую аналогию с директориями trunk и branch, являющихся обычным приёмом при работе с svn). Самый большой прикол заключается в том, что бранчи в полный рост реализованы в меркуриале - но никаким образом не реализована удобная работа с ними:

Почему это полупинок? По двум причинам:

  1. На большинство проблем уже заведены баги, и работа над ними ведётся, хотя это и слабая отмазка. :-)
  2. В большинстве случаев использование бранчей неоправданно и их замена обычными клонами (отдельными репозиториями) создаёт куда более прозрачный цикл работы.

На этом и завершится текущая итерация этой статьи - пока есть надежда, что в будущем она будет расширена для более углублённого гнобления гита сравнения этих замечательных систем.

В принципе, замечания по поводу “это лучше, а это хуже” - приветствуются, особенно личные и субьективные (субьективные не в плане “я щетаю шо субверсион рулед и капец!” ;). Ссылки на статьи… я бы предпочёл пережёванные мысли комментирующих, потому что статей уже сам почитал - пока ни одной вменяемой git vs hg, где гит был лучше, не видел. В основном фанаты какие-то.

P.S. Тут в статье случайно мелькнуло слово svn. Чтоб развеять сомнения в моей ориентации, спешу сообщить - я натурал, svn ненавижу за крайнюю угрёбищность и перманентную порчу последнего года жизни. :-)


  1. О да, ничего иного тут и не задумывалось - гнобление и есть. :-) ↩︎

  2. Голова (head) - аналог конфликта в svn. ↩︎

If you like what you read — subscribe to my Twitter, I always post links to new posts there. Or, in case you're an old school person longing for an ancient technology, put a link to my RSS feed in your feed reader (it's actually Atom feed, but who cares).

Other recent posts

ngrok for the wicked, or expose your ports comfortably
PostgreSQL collation
History snapshotting in TwinSpark.js
Code streaming: hundred ounces of nuances
Useful shell prompt