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

Server-Sent Events (SSE), but with POST
ngrok for the wicked, or expose your ports comfortably
PostgreSQL collation
History Snapshotting in TwinSpark
Code streaming: hundred ounces of nuances