Я уже довольно давно собираюсь написать хоть какое-то примерное сравнение этих двух систем контроля версий - просто потому, что меня это касается довольно прямым образом. Но постоянно не мог собраться - сомнения, как бы начать, достаточно ли я для себя точек сравнения накопил, и так далее… В конце концов решил не тянуть резину в долгий ящик и написать то, что есть. Возможно, если получится мало и спорно, в жарких дискуссиях начнёт просыпаться истина… эээ… это я как-то отвлёкся от темы, приступим к делу. :-)
Итак - два участника. 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’а, что приводит к значительно более раздражающей меня проблеме - адресам у веб-интерфейса. Достаточно сравнить:
- http://git.catap.ru/?p=emacs-jabber.git;a=blob;f=jabber-chatbuffer.el;hb=HEAD
- http://hg.piranha.org.ua/byteflow/file/tip/urls.py
Из обоих убраны идентификаторы ревизии (заменены на символические аналоги
последней ревизии - HEAD и tip). Что легче прочитать? Запомнить? Я очень
часто набираю ссылки по памяти, но с git’ом этот фокус провернуть на порядки
сложнее.
Ещё одна проблема с адресами - у меркуриала один и тот же адрес является
адресом веб-интерфейса и адресом для самого клиента меркуриала: надо помнить
лишь один адрес. С гитом этот номер не прокатит - попробуй догадайся про
адрес у первого репозитория без подсказки? Тут повезло, всего лишь
git://git.catap.ru/emacs-jabber. Но… интерфейс, это интерфейс…
И для этого адреса приходится держать отдельный демон. Который, само собой, о виртуальных хостах не знает ничего, которые сами собой разумеются при работе с веб-мордой меркуриала.
Продвигаемся вперёд по плану гнобления1: набор команд. Не видел ни разу
человека, набиравшего команду status полностью - все пишут st. Обломитесь
- в гите нельзя сокращать команды. Нету автоматических (ну конечно, всегда
можно сделать алиасы)
st,ci, и вообще никаких сокращений команд - при этом в меркуриале кроме предустановленных сокращений хватает любого набора букв, достаточного для несомненного определения команды.
А что мы можем сказать о помощи? У систем огромное количество команд и
возможностей. Помощь в меркуриале - это информация по сути дела. hg help clone - одна страница с описанием поведения при разных условиях и списком
специфических опций. git help clone - 4 страницы текста. Зачем мне столько?
Я хочу краткий хелп, а не руководство. Руководство должно быть в man-pages
или в виде книжки. Когда у меня есть только медленная консоль, это
не может не раздражать.
На этом претензии, накопленные не к фичам гита, у меня пока исчёрпываются - можно лишь благодарить богов, что мне не приходится это чудо использовать так же много, как и меркуриал. К фичам придраться тоже можно было бы, но этого и так хватает в интернетах - к примеру, отсутствие удобного аналога mq.
К завершению подойду полупинком (почему “полу” - об этом позже) в сторону
меркуриала. В гите есть довольно удобная штука в виде бранчей. Это что-то
типа внутрирепозиторийных клонов (можно провести прямую аналогию с
директориями trunk и branch, являющихся обычным приёмом при работе с
svn). Самый большой прикол заключается в том, что бранчи в полный рост
реализованы в меркуриале - но никаким образом не реализована удобная работа с
ними:
hg fetch(который является склеенным скачиванием обновлений и автоматическим их мержем) может поломаться, когда изменения для мержа есть в нескольких ветках.tipстоит не на основной ветке, а на последнем коммите.- hg backout не проверяет, из текущей ли ветки запрашиваемый чейнджсет, или нет.
hg pushопределяет создание нескольких “голов2” только для текущей ветки.
Почему это полупинок? По двум причинам:
- На большинство проблем уже заведены баги, и работа над ними ведётся, хотя это и слабая отмазка. :-)
- В большинстве случаев использование бранчей неоправданно и их замена обычными клонами (отдельными репозиториями) создаёт куда более прозрачный цикл работы.
На этом и завершится текущая итерация этой статьи - пока есть надежда, что в
будущем она будет расширена для более углублённого гнобления
гита сравнения этих замечательных систем.
В принципе, замечания по поводу “это лучше, а это хуже” - приветствуются, особенно личные и субьективные (субьективные не в плане “я щетаю шо субверсион рулед и капец!” ;). Ссылки на статьи… я бы предпочёл пережёванные мысли комментирующих, потому что статей уже сам почитал - пока ни одной вменяемой git vs hg, где гит был лучше, не видел. В основном фанаты какие-то.
P.S. Тут в статье случайно мелькнуло слово svn. Чтоб развеять сомнения в моей ориентации, спешу сообщить - я натурал, svn ненавижу за крайнюю угрёбищность и перманентную порчу последнего года жизни. :-)