Mercurial vs 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’а, что приводит к значительно более раздражающей меня проблеме - адресам у веб-интерфейса. Достаточно сравнить:
- 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 ненавижу за крайнюю угрёбищность и перманентную порчу последнего года жизни. :-)
Comments
Угу. Когда узнаешь про фичу web_ui_url==repo_url, удивляешься, почему этого, абсолютно логичного подхода, нет у других.
P.S.Зачетная фраза “не тянуть резину в долгий ящик” :)
Хм, а для меня она является такой себе старой-старой шуткой. :-)
А где можно почитать разумное сравнение SVN и Mercurial? Я уже давно пользуюсь SVN, и меня в принципе устраивает. Теперь же все время читаю что “Меркуриал это вещь”, но пока особо не вижу, чем он настолько круче SVN - кроме того, что весь репозиторий хранится локально.
Хмм… Я бы лично порекомендовал, если есть время, трафик и какое-никакое понимание английского, посмотреть запись рассказа Линуса Торвальдса с Google Tech Talk о git’е. В принципе, есть её записи текстом, так что можно просто почитать, потому что там целый час - хотя Линус очень понятно говорит.
Первый и главный вопрос - сколько вас работает над проектом? Если трое и вы привыкли к SVN, то первым делом больших преимуществ вы можете и не заметить. Если вас 30, у вас есть бранчи, версии и т.п., то тут вообще без вариантов - мержинг в SVN настолько убогий, насколько он может быть.
Т.е. самое главное преимущество это то, что мерж - атомарная, очень простая, быстрая и удобная операция. Потому разработка в отдельной ветке не выливается в огромные траблы при объединении веток, а является реально удобной операцией.
Что ещё? Для меня порядочным плюсом является возможность не давать прав на запись в основной репозиторий. В сабвершене вариантов нету, в меркуриале - у всех свои публичные репозитории, откуда можно стаскивать изменения в главный.
Опять же, очень легко вести разработку - то, что своими коммитами ты ничего никому не ломаешь, приводит к стилю “мелких коммитов” (что в SVN не только не поощряется, а даже осуждается), где значительно проще уловить место, где случилась трабла и вообще увидеть логику изменений (одно логическое изменение - один коммит, всё прозрачно).
В принципе, преимуществ ещё есть у нас, но наверное проще просто попробовать попользоваться. В качестве просто плюшек приведу ещё несколько не очень значительных, но мне лично приятных пунктов:
.svnв каждой директории, в распределённых - только в корневой)Спасибо!
Права на подкаталоги. Хороший вариант. При нормальной веб-админке позволяет избегать гемора с отсутствием на месте админа репозитория.
Интересно кем это осуждается?
Т.е. не ломаешь? Люди ведь все равно должны стягивать к cебе твои изменения, если хотят иметь последнии версии сорсов? Или хочешь сказать, что в меркуриале этого никто не делает?
Сори, я просто не работал еще с концепциями распределенных репозиториев потому могу задать глупые вопросы. Не работал я с распределеннками в основном по причине того, что не вижу в этом ничего хорошего. :)
Есть такой проект trac. Крайне всем рекомендую. написан на питоне. он в себе содержит отличную вебморду для свн-репозитория :)
P.S.
При частых комитах скорость работы в svn обычно не напрягает. Т.к. изменения не большие обычно. Хотя конечно иногда раздражает - согласен. Особенно если сеть лежит и сервер недоступен.
Ну это ваще не аргумент имхо :)
Кто мержить потом будет? Нет, это не просто несравнимые варианты, это вообще разные концепции.
Ммм… Такой вопрос - ты в больших проектах работал? Короткие коммиты осуждаются потому, что они просто загрязняют таймлайн и усложняют процесс мержа веток.
Не ломаешь - когда ты коммитишь какой-то промежуточный результат. Который важен для тебя, но вполне может поломать что-то на стороне.
Почему бы не попробовать? Твой коммент - суть предубеждения, стоит лишь распробовать и дальше всё пойдёт как по маслу. :-)
Боян. Сравнивать тяжеловесность решений вообще нереально. :)
Меня раздражает коммит больше 1-2 секунд. Когда происходит какой-то тупняк в сети и это затягивается на 10-20 секунд, это просто бесит. Я разрабатываю, а не слежу за разработкой. :-)
Это не аргумент. Это приятная плюшка. :D
а не наоборот???
Не наоборот. В svn никто не любит короткие коммиты.
http://doc.bazaar-vcs.org/latest/en/user-guide/index.html в самом начале
А чего скажешь про Mercurial VS Bazaar?
Вкратце? Не вижу в базаре смысла - коммьюнити меньше, скорость ниже, фич меньше. Плюсов не замечено. :-)
P.S.Хе-хе, спорно написал. Но это я специально. =)
Скорость где-то ниже, где-то сравнимая. Насчет остального — я так понимаю взято с потолка. Иначе — где факты, сэр?
Меряться пиписьками нет никакого желания. Однако твой коммент похоже объясняет ситуацию почему фанаты меркуриала в упор не замечают существования Базара.
А что-то сча мне впадло замерять. Про коммьюнити и фичи, я так понимаю, возражений нету?
Почему ж не замечают-то? Я просто уже не вижу смысла с ним сравнивать и вообще его использовать. Если у тебя другая точка зрения - кто мешает тебе провести сравнение? Я для себя проводил, и решил, что кроме гита и меркуриала для меня интересных VCS сейчас нету больше.
Возражения есть. “Насчет остального” — это как раз про фичи и комьюнити. На чем основано мнение, что их меньше?
Насчет скорости возражений нет. Даже мерять не надо.
То, что ты мерял где-то полгода назад, я помню. И что для тебя лично Базар не интересен — мне тоже понятно. Посему это флейм поддерживать мне интересно.
ЗЫ: твои нападки на гит выглядят притянутыми за уши. Особенно пример с урлами. Че-нить посерьезнее накопай, а?
s/Посему это флейм поддерживать мне интересно./Посему это флейм поддерживать мне НЕ интересно./
На фактах. Где используется базар, кроме лончпада? Меркуриал используется в ряде крупных проектов (включая Мозиллу). С фичами - та же ситуация. Почитай hgbook и доки базара, посмотри на плагины меркуриала.
То, что у базара до сих пор веб-морда находится в состоянии стагнации, это тоже прикол.
Ну тогда мне непонятно, что конкретно от меня можно хотеть? Если у тебя есть возражения с цифрами, ссылками - я готов слушать. Если нет - то я приводить не собираюсь, потому что это лишняя морока, мне с ничего не интересная.
Зачем ты это делаешь тогда? Преврати флейм в обсуждение.
Чё-та мне фпадло, э?
непонял я замечания про веб-морду. вот: https://launchpad.net/loggerhead
я лично пользую интеграцию trac+bzr.
Просто отлично. То, что я должен многомегабайтный фреймворк за собой тащить, это просто весело.
Я не напасусь жизни для всех репозиториев ставить трак. У меня их уже десяток (меркуриал + гит).
я свои опен-сурс проекты держу на лончпаде. а для работы стоит трак, в нем более 20 разных подпроектов основного проекта. один раз поставил и меня не парит.
Тут немного другая предпосылка.
Что нужно, чтобы расшарить репо? Что нужно сделать, чтобы этот репо был human readable? В случае hg достаточно одного:
hg serve.Теперь задайся таким же вопросом про bzr, git.
чтобы расшарить репо достаточно залить его на любой сервер, способный отдавать файлы в режиме http. что такое human readable? я могу сделать bzr log http://server/path/to/branch и получить лог ревизий, как будто эта ветка лежит у меня на винте. этого достаточно?
git, насколько я помню, тоже позволяет хостить репозиторий на тупом http.
Значит на фактах говоришь?
http://bazaar-vcs.org/WhoUsesBzr
Статистика по лончпаду здесь: https://code.launchpad.net/
Цытирую (читать внизу страницы):
7850 branches registered in 3026 projects 1709 imported branches 566 branches associated with bug reports
Кто из них крупный? Проектов размера Мозиллы и линухового ядра я не вижу.
Статистика по этой свалке неинтересна никаким образом. На sourceforge тоже можно тыкать пальцем, и то там свалка меньше.
а наверное и нету там ни мозиллы, ни линухового ядра. вон Emacs пытаются перевести на Базар. Это конечно слегка политический ход со стороны Столлмана, многие рады бы использовать git вместо bzr.
Ругают bzr за медлительность в некоторых местах. Разрабы bzr чешут репу и пытаются исправить. Шо есть, то есть.
Я читал hgbook по диагонали и внимательно читал доки базара. Конкретнее давай наезжай. То, что в базаре есть фичи которые отсутствуют в меркуриале считать не будем? Раз этого нет в меркуриале, значит тебе лично оно типа не нужно. значит и считать не будем, правильно?
Смотрю на плагины. То, что у вас в плагинах, у нас давно в ядре. Кое-чего нет в базаре — я придуриваться не буду. Точно также чего-то нет и в меркуриале из базовых возможностей базара. а также его плагинов. Даже простой пересчет на пальцах плагинов базара и меркуриала показывает, что уж по количеству у нас больше: 38 у меркуриала и больше 50 у базара (не считая разных экспериментальных). При этом где-то полдюжины плагинов меркуриала — это встроенные команды базара.
Скучно, Александр. Окромя оголтелого фанатизьма в твоих словах нету ничего.
Неправильно. Ты пришёл ко мне в комментарии. Ты и приводи факты. Т.е. не количества, а какие-то фичи базара, которые бы пригодились в меркуриале.
А то ты уже со словами про фанатизм повторяешься который раз, а реальных каких-то слов (а не просто флейма) добился я от тебя аж на 4 уровне треда.
P.S.Прикол в том, что половина плагинов базара в меркуриале не нужна. Типа генераторов Atom’а, или там закладок…
Я рад, что ты все-таки подтвердил мое высказывание, что если какая-то фича в меркуриале не реализована, то она не нужна, следовательно ее и считать за фичу не будем.
Все эти плагины написаны живыми людьми и ИМ лично для чего-то это было нужно. То, что базар это не меркуриал, надеюсь уже понятно всем.
Приводить фичи, которые есть в базаре и “которые бы пригодились в меркуриале” — нах оно мне нужно? Чисто ради академического интереса? Если бы у бабушки были яйца, это был бы дедушка.
Для меня неопреодолимым барьером для использования вашего любимого меркуриала является менее удобный интерфес командной строки в меркуриале (в базаре — лучше, уж поверьте) и отсутствие встроенного merge. Сутью любой распределенной системы является поддержка веток и последующего объединения изменений. Такая поддержка объединения как в меркуриале — это хуже чем требование постоянного rebase в git. Спасибо, мне такого не надо.
Насчет фанатизма: в статье про бородавки в питоне Andrew Kuchling заметил, что только тот, кто видит кроме достоинств в своем любимом инструменте еще и недостатки, только того можно назвать экспертом в данном инструменте.
Я как один из активных разработчиков Базара могу рассказать о многих (не обо всех, но почти обо всех) его недостатках. Я способен анализировать его критически. Способен ли ты анализировать критически Меркуриал? Ну что-нить посерьезнее чем снисходительные полупинки?
Признаю, что Базар — говенная система, потому что она в пару раз медленнее меркуриала. Вы довольны? Тогда я пошел дальше в своем говне ковыряться. Меня его скорость устраивает. И мне нужны все те фичи, которые есть в Базаре и которых нет в Меркуриале.
Глаза раскрой! И фанатизму поумерь, потому что уже задолбало.
Не нужно, потому что они реализованы в ядре, в hgweb’е, во многих других местах.
Ну и нахер Вы тогда сюда заявились? Посрать в комментах? Нечего/лень сказать - об этом можно в ЖЖ лытдыбрить, а не в моих комментариях.
ФАКТЫ.
Давай. Это просто будет счастьем.
так хто ж требует? хочется мержа - пожалуйста.
вместо git st я набираю git-st Tab.
никто не заставляет юзать демона - можно настроить ssh доступ. с созданием удалённых репозиториев - оно такида, да и создание бранча в удалённом репозитории, не вставая с локальной тачки - не очень короткая команда, но жить можно.
дальше - git-http-push - Push objects over HTTP/DAV to another repository, такшта ведморда быть должна.
и ваще, пешы разрабам, они, думаю, обрадуюццо.
Итого три недостатка:
:P
Чо? Забудь про ssh, у тебя либо git-daemon, либо http+webdav. Первый вариант мне не нравится левым процессом, второй - левым модулем в апаче (который и так кушает плотно).
Жить можно и с сабвершеном. Я писал не о том, что пользоваться им нельзя, я писал о том, что меркуриал просто удобнее - потому я его и выбрал. А то вокруг достаточно много людей, которые либо не могут выбрать, либо не дают себе труда взвесить решение. :-)
Она есть, но она вебдав. Ну и она выходит медленее, чем отдельный демон.
Рассказать секрет? Не обрадуютсо. Им и так пишут. :-) Я лучше пойду помогу что-то сделать для бранчей в меркуриале.
да ладно, они же тоже люди. скачай репу, посмотри ветку TODO - туда всё пишут, что планируецо.
Еще проще это сделать удалённо, так что проблемы особо и нет
Я не особо знаком с Mercurial (вероятно, стоило бы и его посмотреть), однако, в статье бы хотел увидеть освещенными другие пункты:
Скорость и объемы занимаемой памяти (например, GIT меня приятно поразил)
Возможность интеграции с SVN (ведь большинство уже существующих проектов пользуется именно этой системой контроля версий)
Ибо в статье в основном - удобство использования, а так как я избалованым весьма приятными на мой вкус графическим клиентом для SVN (tortoise), то вообще любой ориентированный на командную строку интерфейс системы контроля версий считаю неудобным(и это ведь всё так субъективно! :) )
У mercurial есть отличный GUI: emacs+dvc. :) Кстати, tortoise-hg тоже существует.
Что проще сделать удалённо? Склонировать репозиторий, находящийся на машине в серой сети?
На память не обращал внимания, какие-то копейки. Скорость у меркуриала и гита практически одинаковая.
hgsvn, но в любом случае это костыли - всё равно придётся работать с SVN. Я предпочитаю этого не делать, просто чтоб самому легче жить было.
TortoiseSVN - не самая удобная для работы штука. :P
Это провокация? :-) В гуе можно задолбаться искать то, что мне нужно. Для каждой задачи - своё решение. Когда мне надо посмотреть diff - я предпочитаю программу с GUI, когда мне надо сделать что-то, что удобнее сделать из коммандлайна - я так и делаю. А TortoiseSVN вынуждает меня хвататься за мышку для любого действия (читай - раздражает и замедляет).
Вероятно, я просто не понял, что вы хотели сделать.
А вы сравнивали? Меня интересует чуть более точное сравнение, чем “практически одинаковая”(хотя за сверхточными цифрами я и не гонюсь)
Я же сказал - это всё субъективно. И точку зрения, не совпадающую с моей, я уже слышал множество раз.
Ни в коем случае! Я даже не стану спорить о том, что изучение возможностей командлайновских клиентов требует не меньше времени, чем поиск нужной функциональности в гуях, а основные операции выполняются так же быстро как из командной строки(более того, их можно и из командной строки выполнять, если хочется еще быстрее). А нет, вот уже и спорю, но лучше не обращать внимания - очень редко в подобных спорах рождается истина.
Ну да, не совсем очевидная вещь. :-)
Не-а. Меня это не беспокоит, потому и не сравнивал…
:D
Я уже года три как пользую svn, в принципе терпимо, но сильно достают мерджи с конфликтами, невозможно отследить что уже слил а что нет (приходится писать в описании коммита), а с ростом числа файлов сильно упала скорость. Зачитал hgbook до дыр в мониторе, но никак не получается безболезненно для мозга перейти на меркуриал.
Может кто-то попробует осветить различия в философии на практике? К примеру, у меня несколько бранчей (как обычно, /trunk/, /dev/, /local/) в одном репозитории. Стоит задача потянуть к примеру НЕКОТОРЫЕ changesets из /local/ и слить на /dev/ для тестирования, потом (возможно), сделать несколько изменений прям на /dev/, перекинуть финальные на /trunk/, и соответственно сделать обратно синхронизацию на /local/. Пытался сделать это с бранчами внутри hg, такого гемора не пожелаю никому (hg pull гребет все изменения подряд и проч.)…
Чувствую, что где-то я свернул не туда… Вот встретилось нехорошее упоминание про бранчи, думаю в этом проблема. Какие best practices существуют? Как лучше организовать разработку для моей модели (один live server, один dev и несколько local)?
Это порочная практика сабвершена. :-)
Делай несколько разных репозиториев, которые и будут твоими trunk, branches, etc.
В репозитории на дев-сервер могут пушить все, в live-сервер - только избранные. Соответственно разработка идёт на деве, когда какая-то фича кажется готовой - она переносится в trunk/stable/как-там-это-у-вас-называется, и пушится на лив-сервер.
Ещё как вариант с разделением на команды - в транк могут пушить только тимлиды, а члены команд каждый пушит в свой личный репозиторий на сервере. При этом тимлиды собирают кажущиеся для них нормальными изменения и пушат их в транк.
Anyway, много бранчей в одном репозитории - не очень удобно, да и совершенно не нужно в DVCS.
Ок, примерно ясно, остались детали :)
Что есть trunk/stable/… ? Путь внутри какого-то репозитория или отдельный репозиторий или что?
Идет работа над web-проектом, соответственно настроен live сервер, dev сервер и локальные серверы у разработчиков. Чем удобны бранчи - тем что работая в одной рабочей директории (которая является documen_root для сервера), я могу переключаться (switch) на любую линию разработки и мне не надо перенастраивать сервер или переименовывать docroot. Как можно такое осуществить в hg? Там же нормой является куча репизиториев (читай - директорий), получается мне каждый раз надо менять docroot на тот репозиторий, в котором я хочу работать (или наоборот, переименовывать репозиторий, чтоб совпал с docroot)?
Еще, предположим я что-то меняю в local ветке. Сделал 10 commits, потом решил слить на dev для проверки 5 из них (не последних). Я делаю на dev нечто типа svn merge /local/www/ -r 12:17 и получаю сделанные на local изменения для проверки. Мало того, перед слиянием я могу скомандовать тоже самое с —dry-run и посмотреть? что именно будет меняться и с каким результатом (например, если будет конфликт, я могу провести слияние в другом месте, чтоб не валить сервер метками конфликта).
В hg, pull или push скидывает все изменения до какого-то ревижина. Можно ли получить выборочно changesets, а не все подряд? Можно ли посмотреть что будет обновлено и с каким результатом?
Отдельный репозиторий.
Без бранчей… Честно говоря, ни разу не задумывался, потому что у меня при такой же разработки веб-сервер просто запускается из самого проекта. По сути дела симлинка должно хватить. :-)
Выборочно - можно, посмотреть входящее/исходящее - тоже можно.
Вообще на большинство вопросов есть ответы в книге. :-)
Не знаю как в hg, в гит ты для этого делаешь отдельную ветку (назовем ее master), которая соответствует удаленной (origin/master), отдельно ветку для разработки (work). После жтого ты работаешь на work, когда хочешь запушить что-то в origin/master, то делаешь checkout ветки master, затем cherry-pick на нее тех коммитов из work, которые хочешь запушить, ну и наконец пушишь master на origin/master.
Кстати, ещё раздражает обилие терминов. master, origin/master… Если работаешь только с гитом, то избыточность не сильно видна. Если ещё и с меркуриалом - то просто очевидна.
Это не термины, это названия веток. (ну origin - еще и алиас для конкретного удаленного репозитория)
Yup. :-)
Если заменить в этом комментарии “ветка” на “репозиторий”, то это же и для hg равноприменимо.
Угу, только лишний репозиторий - это сильно больший оверхед, чем лишняя верка. Просто на уровне удобства работы. Хотя, конечно, позволяет реализовать все то же самое. Кстати я вот по одному проекту решил что разработчики коммитят в главный репозиторий на свои ветки, а я с этих веток черри-пик делаю, если меня коммиты устраивают. Просто потому, что мне приятнее иметь центральный репозиторий, чем подключать несколько репозиториев других людей. То, что называется, частичная децентрализация.
А для нас отдельные репозитории в этом случае удобнее - мы можем запускать для каждого по инстансу сайта, где он может демонстрировать, что ж он натворил. :-)
Слегка удобнее, да.
Не нужно скакать по директориям:
Да и репозиторий выступает индексом для всех веток. Т.е. было бы неплохо, если бы нормальные named branches в hg всё-таки появились :)
Меркуриал практически не использую, поэтому вопросы:
Есть ли в mercurial rebase? Насколько в mercurial можно менять локальную историю (не последний коммит, а именно какой-то коммит из глубины)?
ЗЫ От гита фанатею последние полтора месяца.
Оно?
Практическое применение какое? Вообще, вроде бы нельзя, что и хорошо. Уверенность не стопроцентная
Не оно. Rebase - это зло. В свете существования mq мне кажется его существование даже несколько вредным. ;-)
Почему же вредным. есть upstream v1 ты на нем делаешь свою ветку и туда коммитишь. вышел upstream v2 - ты его загоняешь на ветку upstream, создаешь новую ветку mywork_based_on_upstream_v1 основанную на твоем текущем work, после чего сам work rebase’ишь на HEAD upstream’а.
Ну или когда я делаю в локальном репозитории новую фичу, за это время HEAD убегает вперед, я переодически хочу сихронизировать эту локальную ветку в удаленным master’ом. rebase в этом случае весьма удобный инструмент.
mq - это попытка реализовать quilt. Это не совсем то. Хотя и позволяет решать поставленную задасу несколько более извращенным способом.
насколько я вижу из списка рассылки hg у них там на mq завязано куча функциональности. которая в гите и базаре делается более прямыми методами.
Кроме rebase? А что ещё?
кстати, в списке расширений меркуриала я видел rebase. Значит он кому-то нужен? Несмотря на mq?
rebase - commit-based, mq - patch-based.
сам ты зло.
если делать ребейз вместо мерджа, история становится прямой, по ней бисекцию багов, в частности, делать проще. коммиты тогда расположены не в хронологическом порядке, а в смысловом.
интересный аргумент. и я даже как-то с этим согласен. учитывая, что гит и меркуриал мешают в одну кучу все фиксации. в базаре эта проблема не стоит так остро, потому что базар разделяет основную историю ветки и объединенные (merged) ревизии. Поэтому bisect по основной истории будет быстрее локализовывать проблему в плане: “чьё объединение внесло баг”.
типо да.
плюс ещё один нюанс: мердж подходит больше для схемы “есть n разных веток, которые живут по три года и переодически скрещиваются”, ребейз лучше подходит для “для решения задачи на неделю/месяц группой отдельных товарищей создаётся ветка, которая потом махом вливается в мастер”. я свои патчи к фрёвым портам, кстати, храню в вершине как раз методом ребейза, чтоб было видно, что и когда аппрувится в мастере.
merge — во всех 3х системах (hg, git, bzr) выполняет немножко разные вещи. хоть и называется одинаково.
Mercurial Queues
Ну сделал ты изменение. Потом еще одно, потом третье. Потом понял, что первое изменение было не совсем корректным. Тогда, при условии, что эта конкретная ветка никуда не экпортируется и никем не используется, ты можешь поправить вот тот конкретный коммит. В частности это помогает мне требовать от co-workers более аккуратных коммитов и облегчает соблюдение правила commit-per-modification.
Угу, похоже позволяет, хотя и несколько менее органично чем гит.
Вообще видно, что ты мало пользуешься ветками - именно при их использовании всплывают преимущества гита перед hg. (Насчет суперидеи поста, что гит менее очевиден и удобен для простых ситуаций - совершенно не спорю.) А в гите ветка - это очень дешевая и удобная вещь. Например feature-branch довольно-таки удобно реализуются.
История для того и история, чтобы её не модифицировать. ИМХО.
P.S.Ставь плиз энтеры между любыми абзацами, а то маркдауну крышу срывает.
Смотри, у меня есть подчиненный. Он делает пуш нескольких коммитов “новая фича”. Я ему говорю - что за фигня, он делает коммит “исправление в новой фичи”, я говорю - ну кто так коммитит, у тебя два логических изменения в одном коммите. В итоге в истории несколько исправлений и четко понять уже ничего нельзя. Если мы хотим этого избежать - в hg придется для этого плясать с ветками и перетаскиванием коммитов с ветки на ветку (иногда ручному), в git это делается довольно просто (хотя, конечно и не тривиально).
Имхо интереснее его ударить по пальцам, чтобы больше так не делал. :-) Изменение истории - это плохо.
В меркуриале есть
rollbackдля последней ревизии. А дальше - ССЗБ.Изменение некоторой глобальной истории (ну точнее истории в репозитории, который расшарен и кем-то используется) - это плохо. В своей песочнице я могу делать что хочу. А по пальцам бить - жестоко это, если человек просто недостаточно квалифицирован, чтобы понять, что некоторые его изменения неправильны.
в bzr глубина uncommit никем не ограничивается. очень удобно. был сильно удивлен, когда увидел, что меркуриал позволяет убрать только последнюю ревизию.
hg strip
Кстати в защиту svn:
В случае, если в VCS хранится довольно большое дерево бинарников (У нас это документация к проекту в формате doc), то git сильно проигрывает svn’у тем, что не позволяет вытащить только один подкаталог, а клонировать весь репозиторий - слишком накладно.
ЗЫ Кстати git-daemon проще всего добавить в inetd.conf все равно он весьма редко бывает нужен. ЗЗЫ O! Придумал фишку. Можно git-daemon’у разрешить анонимный пуш на специальную ветку. И потом оттуда cherry-pick’ом патчи вытаскивать :) Только делается это через жо… ну в смысле по-гиковски. Проверкой в хуках.
Хранить документацию в .doc - это зло. Но можно просто сделать отдельный репозиторий. :)
Конечно зло, но если заказчики - военные, которые хотят доки, при чем с ихним военным форматированием… Приходится нанимать специального человека, который будет “писать и верстать в Word” (c)
Ну тогда отдельный репозиторий. :-)
Угу, в svn. Так и живем.
Кстати, я правильно понимаю, что в hg клонируется тоже только репозиторий целиком?
Правильно. Во всех распределённых так.
Теперь я буду знать к кому по поводу меркуриала обращаться ))
К книге будешь! :-)
Извините, но читается как будто человек не пытался разбираться в предмете (я не наезжаю!) - простейшие примеры:
ssh-доступ к репозиториям есть. git clone git+ssh://denis@git.dev.troll.no/home/denis/dotfiles
Автодополнение команд git имеется в любом шеле, по крайней мере в bash и zsh нет проблем набрать хоть git-st[HTML_REMOVED] хоть git st[HTML_REMOVED]. Про алиасы вы упомянули. я сам пользуюсь сокращениями типа g s (status); g d (diff); g a file[HTML_REMOVED] (авторасширяется до измененного файла даже если он в подкаталоге); g dc (diff —cached) g c (commit).
лично я работаю в ветках постоянно, но это дело лично каждого. Хочу только отметить что git поддерживает оба способа работы - см. git-new-workdir (в windows не работает - но для windows имеется другое решение которое я использую).
Про количество команд в …/bin - честно говоря я даже не знал что там столько утилиток. Вас это действительно волнует? :)
Возможно не затруднит ещё раз перечитать статью, на этот раз внимательно?
Да. Меня волнует не только фичи, но и внешний вид, и внутреннее содержимое. =)
честно - все равно не понял про ssh. репозиторий находится на машине piranha.org.ua/dev/byteflow и вы хотите там же в другом каталоге создать клона а потом его забрать по ssh? в man git-clone что-то упоминается что можно указать удаленный каталог - но я бы в любом случае сделал по другому - “ssh piranha.org.ua git clone …”
а если на piranha.org.ua не поднят ssh или серый ip.
не, притензия вполне имеет право на существование.
Нет, репозиторий находится локально.
понятно. похоже так в git в одну команду нельзя сделать. но все равно претензии лично мне непонятны - я сам git впервые попробовал меньше полугода назад, а активно начал использовать два месяца назад. Но недавно попробовав mercurial почувствовал кучу таких же “недостатков” которые imho просто следствие переноса своих способов использования однго инструмента - на другой. что imho некорректно. А вообще основную задачу оба инструмента выполняют отлично - а мелкие “рюшечки”, подобные вышенаписанным, допиливаются по ходу дела (например последная такая штука - git pretty-diff - показать diff из стории в gui-режиме в стороннем diff/merge tool).
В гит так сделать просто нельзя. В одну, не в одну - нельзя. Мне придётся пользоваться другими инструментами, которые под виндой крайне несовершенны, к примеру. :-)
Я жду список. :) Я не все проблемы гита упомянул, тем более практически не затрагивал его фичи (как выше было сказано - жить можно). Меня в основном поражает общая неконсистентность, непостоянство и вообще полнейший бардак интерфейса. Причём в таких неожиданных местах, что просто ой.
Просто хотелось бы привлечь внимание тех, кто ещё колеблется (и заставить сомневаться уверенных :)) к тому, что меркуриал - приятнее гита в использовании. :-) Просто потому, что git был порядочно пропиарен Торвальдсом, а питон и околопитоновские проекты вообще отличаются чуть ли не полным отсутствием пиара - на гит обращает внимание куда большее количество народа.
А, естественно, я бы предпочёл видеть ускорение развития “правильного” проекта, который удобнее и грамотнее.
Давно не был ты на git.catap.ru, ой давно. Прошу посмотреть какие ссылки нынче там.
Хм, вчера скопировал оттуда… Ну, сегодня не намного лучше:
Но согласись, что предераться к web-морде это низко. Ибо в hg’шной мне не нравится отсуствия ссылки projects.
Вообще мой выбор git’а прост. Я знаю его лучше.
И кстати, я тот человек что пишет hg status, ибо на работе используем ее.
Не-а. :-) Это юзабилити. :)
Хмм… ну это же одна строчка в темплейте. :)
Хммм… Когда-то ты и емакса не знал, и линуха, не так ли? :)
Ну так клёво! :-) Дописать бранчи не хочешь? :)
Для меня, как проьзователя git его веб-морда второстепеное юзабили. Вот бранчи да. Но дописывать их желания нет. А вот научить git понимать hq’шный репозиторий, очень большое.
а разве git не умеет работать с hg репозиториями? я “не в теме” но на работе общались на тему отличий git и mercurial - вроде можно легко отконвертировать одно в другое.