Ещё раз о «Mercurial против Git» (с картинками)

http://jhw.dreamwidth.org/2049.html
  • Перевод
Некоторое время назад я опубликовал очень многословное сочинение, где пытался объяснить, почему Git серьёзно поломан, и почему всем следует вместо этого пользоваться Mercurial, до тех пор, пока разработчки Git его не починят. Ну ладно, я был не настолько груб, но близок к этому.

Народ на Reddit жаловался, что мой технический язык слишком путанный, особенно потому что я придумывал новую терминологию в попытках доказательства своих положений. Они потребовали графы, с узлами, рёбрами, кружочками, стрелочками и всем прочим. Тогда я промучал графический редактор несколько часов и получил два графа, приведённые ниже, которыми я надеюсь обрисовать проблему.

Ниже я нарисовал упрощёный граф истории репозитория Git с тремя созданными ветками: «master», «release» и «topic». До того, как энтузиасты Git начнут ругаться, что я исхитрился показать нереально плохой случай запутанности истории, позвольте мне заверить вас, что это на самом деле ещё упрощённый пример. У меня есть доступ к реальному репозиторию Git, где создано шесть рабочих веток релизов, около сорока рабочих тематических веток и несколько сотен ранее существовавших веток, которые уже удалены с центрального сервера.

Вот этот граф. Можете ли вы мне сказать, на какую ветку было зафиксировано изменение ab3e2afd? Какое было самое ранее изменение на ветке «release»? Где именно началась ветка «topic»?
Git

Я знаю, это нечестно. Я не показываю вам журнал изменений. Но поверьте мне, вы не захотите его видеть. Он не поможет. Вы думаете, одомашненные приматы[1] записали там полезные подсказки, которые ответили бы вам на эти вопросы, но они не сделали этого. Хуже того, иногда они врут.

Более умным опровержением моих вопросов было бы спросить «А зачем тебе это нужно знать?» Давайте я отвечу на это последовательно.
  1. Мне нужно знать на какой ветке было зафиксировано ab3e2afd для того, чтобы знать, включать ли его в описание изменений будущего релиза.
  2. Мне нужно знать какое изменение было первым в ветке «release», потому что я хочу начать новую тематическую ветку с этого изменения в качестве начальной точки так, чтобы я всегда был в курсе происходящего в главной ветке насколько это возможно, и быть уверенным, что смогу выполнить чистое слияние в главную ветку и выпустить релиз.
  3. Мне нужно знать где началась ветка «topic» для того, чтобы я мог сложить все патчи вместе и отослать их своим коллегам для рецензии.
Большая часть помешательства, которая толкает пользователей Git на горячие споры на тему «rebase» против «merge», вызвана тем, что они очень сильно хотят заставить разработчиков значительно переделывать историю в своих локальных репозиториях, для того, чтобы граф изменений на общедоступных серверах не выглядел бы как граф, показанный выше.

Пользователи Mercurial, в большинстве случаев, не нуждаются в таких неестественных принуждениях. И вот почему:
Mercurial

Видите разницу?

Каждый узел в графе раскрашен, чтобы показать имя своей ветки в Mercurial. Всякая угадайка становится не нужна. Вы твёрдо знаете, что когда-то была ветка с именем «temp», которая затем влилась в ветку «release», а не «master». Вероятно, сейчас она отмечена закрытой, как больше не нужная.

Некоторая первоначальная работа над веткой «topic» ушла в ветку «temp» перед тем тем, как слилась с веткой «release». Позднее, ветка «release» была обратно влита во вновь ведущуюся ветку «topic».

Всё это становится возможным потому, что Mercurial хранит имя ветки в заголовке каждого изменения. Git тоже должен бы делать так, но не делает. Вместо этого, Git поощряет пользователей подделывать историю как если бы она была «чистой», но на самом деле неприглядна.

Самое печальное, что большинство пользователей Git, похоже, имеют концептуальный блок против даже признания того, что здесь есть проблема. Они принимают необходимость такого исторического ревизионизма, которую их иструмент накладывает на них, и называют это достоинством.

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



[1] Одомашненные приматы — вероятно, отсылка к Тимоти Лири или Роберту Антону Уилсону — прим. перев.
Поделиться публикацией

Похожие публикации

Комментарии 129
    +23
    Когда мне самому пришло время сделать выбор, я тоже пришёл к тому, что Merculial удобнее и логичнее для меня, как говорится «ложиться в руку». Но определённое давление со стороны сообщества (подавляющее большинство проектов, которые мне интересны, используют git в общем и github в частности) заставило «смириться» и перейти на git.

    Я это говорю не с целью продемонстрировать слабость своей воли ;) Скорее, чтобы сказать, что давайте уже программировать, а не играться с системами контроля версий.
      0
        +8
        hg-git.github.com/
        ваш фидбэк приближает тот день, когда git станет не нужен
        • НЛО прилетело и опубликовало эту надпись здесь
            +5
            github станет не нужен
            вообще-то github — платформа для совместной разработки ПО, а не только хостинг репозиториев git. Странно, что это вообще оказалось нужно озвучивать.
              +1
              в лучших традициях филосораптора
              +1
              • НЛО прилетело и опубликовало эту надпись здесь
              0
              Вы можете сформулировать свои ощущения в пользу «логичнее и удобнее», и неудобства, которые приходится терпеть, «смирившись»?
              –6
              Я был бы согласен, если бы не убогость и неудобство использования меркуриала с ветками вообще.
              И единственное достоинство — принудительный трекинг ветки — решается административным способом — заставлением писать номер бага в комментариях.
                +1
                По-моему в последних версиях меркуриала на уровне ядра существует поддержка т.н. bookmarks — аналог веток гита. А так, плюсы гита — скорость, плюсы меркуриала — питон (то есть, в теории лучшая переносимость… хотя на практике проблемы все-равно есть).
                  +11
                  ммм… а что не так с ветками в hg? в чем убогость?
                  тем более, что ветки из git с недавних пор там тоже есть (bookmarks)
                  можно выбирать, какой подход использовать.
                  rebase тоже есть, если очень нужно.
                    +3
                    Пожалуйста, поясните, что вы имеете в виду под словами «убогость и неудобство использования меркуриала с ветками вообще».
                      0
                      Мне кажется, имеется ввиду то, что меркуриал явно хранит информацию о ветке, то есть ее нельзя просто закрыть путем мержа с другой веткой. Тогда как в гите ветка — просто набор изменений. Кому-то это нравится, а кому-то нет :-)
                        +7
                        Ветку можно закрыть, указав ключ hg commit --close-branch, тогда она перестанет мельтешить в списке. При желании потом список всех как открытых так и закрытых веток можно посмотреть через hg branches --closed
                          0
                          Я выбрал плохой пример :-) в статье как раз-таки и написано о том, что каждый ченжсет «помнит» в какой ветке он был создан. А в гите со временем, после нескольких слияний, такая информация теряется.
                          +5
                          Набор изменений — это как раз ветка в hg. А ветка в гит — указатель на голову.
                        +5
                        В меркуриале есть несколько способов работы с ветками (в git я знаю только два, в Hg — по меньшей мере 4, включая те, что есть в git).
                        В принципе, когда я начинал знакомиться с Hg там действительно было похуже с ветками, чем в Git. Но это было года два, а то и три назад.
                        +1
                        достаточно просто метить тегами сборки в релизных ветках, тогда будет ясно что и когда изменилось с последней сборки. Без этого, действительно, возникает путаница при слияниях
                          +15
                          Автор сего опуса не осилил тэги. Cool story bro.
                            +12
                            Да, он жалуется на то, что неумение пользоваться Git привели его в полную жопу :)
                            +4
                            У Git-а есть GitHub и огромная комьюнити.

                            У самого почему-то сердце больше лежит к меркуриалу, но простота пользования github'ом просто подкупает.

                            Да и для компании сейчас рассматриваем покупку GitHub Enterprise со всеми его фичами.
                              +2
                              варианты:
                              — новый сервис для hg, аналогичный github
                              — github введет поддержку hg
                              — hg так и останется, более удобным, но менее распространенным
                                +9
                                А чем bitbucket не аналог github? Да, менее фичастый, но тем не менее (плюс теперь пилится atlassian).
                                Ну и субъективно, мне hg не кажется более удобным, чем git.
                                  0
                                  гм, а там есть аналог гитхаб энтерпрайз? сходу не наткнулся.
                                    +4
                                    По-моему нет (скорее всего пока). А чем для энтерпрайза не подходят платные аккаунты с закрытыми репозиториями? Ведь все данные летают по ssh.
                                      +2
                                      Дело в том, что политика компании, с которой я сейчас работаю (онлайн бухгалтерия) не позволяет хранить исходники где-то кроме своих дата серверов. И это одно из требований клиентов (тот же BDO проводит мониторинг безопасности компании).

                                      Даже из дома нельзя работать с сорсами :)

                                      В данной ситуации GitHub Enterprise является очень хорошим решением.

                                      К сожалению большинство альтернатив не позволяют «хостить» их систему у себя, не считая opensource-вариантов (типа Gitorious), но компания не имеет желания тратить ресурсы на сопровождение системы, и нужен полноценный коммерческий саппорт.
                                        +1
                                        Вот зануды :-) Но я думаю, что атлассиан со временем должен что-нибудь выкатить для таких компаний. Не зря ведь они битбакет покупали.
                                          +2
                                          Есть Kiln от FogCreek. Мне кажется вполне себе подходит под ваши требования.
                                            0
                                            Когда я давно смотрел на это, мне показалось, что это какая-то обертка вокруг меркуриала (а не просто сайт). Или я плохо смотрел?
                                              +3
                                              Плохо смотрели наверное.
                                              Там есть как обертка, так и интегрированный багтрекер.
                                              Ну и бонусы в виде коментов и всего прочего. Собственно там есть демо, и
                                              The Fog Creek Promise

                                              If you’re not satisfied, for any reason, within 90 days you get a full refund, period, no questions asked. We don’t want your money if you’re not amazingly happy.
                                          +1
                                          тем что не многие хотят хранить код на чужом сервисе. Политика безопасности же.
                                      +9
                                      Есть же bitbucket.org!
                                        +2
                                        есть, я сам его юзаю
                                        но по удобности и раскрученности он явно не дотягивает до github, к сожалению.
                                          +2
                                          Не могли бы Вы перечесть те явно необходимые в работе удобства без которых Вам так жаль?
                                          И причем тут раскрученность?
                                            0
                                            вроде по фичастости они практически равны
                                            а так остается более приятный и удобный интерфейс, багтрекер, скорость и стабильность работы сайта. Что для удобства работы с сервисом решает.
                                            раскрученность при том, что если бы не github, то hg сейчас бы был более распростанен (вероятно). Github это локомотив git.
                                              +2
                                              воот. люди пользуются git в первую очередь затем, чтобы контрибутить в проекты на github (ядро linux), а вовсе не потому, что кучка скриптов на С и bashgit лучше и понятнее.
                                                +4
                                                >проекты на github (ядро linux)
                                                Там просто зеркало
                                      +6
                                      Не вижу, чем использование BitBucket принципиально отличается от GitHub (по простоте). И платные аккаунты там тоже есть.
                                        +15
                                        Я бы даже сказал, что bitbucket лучше в плане бесплатности. Он, в отличие от github, позволяет иметь приватное репозитории на бесплатном аккаунте. Для кого то это может что-то решать.
                                          +1
                                          Для меня это вообще стало решающим фактором, ну не готов я пока свой код в паблике держать.
                                            0
                                            Assembla позволяет то же самое для git.
                                          0
                                          Еще можно посмотреть на Atlassian Stash, аналог гитхаб ентерпрайз, но с меньшими ограничениями и по более вменяемой цене.
                                          +14
                                          «Самое печальное, что большинство пользователей Git, похоже, имеют концептуальный блок против даже признания того, что здесь есть проблема.»

                                          Действительно. Сколько лет пользуюсь всякими репозитариями, первый раз вижу такие запросы. 1 — обычно список изменений пишется по багтрекеру. По логу репозитария тоже можно, но зачем при этом видеть, в какой ветке писался фикс? Просто просматривается список коммитов в ветке, не важно, откуда они замержены. 2-3 — тоже какое-то надуманное. Мерж надо верифицировать в совокупности (всю его разницу с целевой веткой), а не по принципу «вот эти строчки — они приехали из другой ветки, поэтому их не верифицируем». Начинать новую ветку никогда не было нужно было «оттуда же, откуда другую», а с головы или с определённого известного коммита. Ну и, естественно, есть такая вещь, как теги.

                                            +10
                                            Меня всегда удивляло, как люди, приближенные к IT и знающие английский язык лучше обычных людей, умеют коверкать обычные слова так, как обычный человек никогда не додумается. Я пока таких слов наблюдаю два: хИдер и репозитАрий.
                                            Прочитав незнакомое доселе слово header, обычный человек скорее всего прочитает это правильно (как хэдэр), потому что знает как читается слово head. От половины знакомых сишников\сиплюсистов я слышу убийственное «хидер». Но в принципе за это еще можно простить — произношение буквосочетания «ea» является одним из самых аномальных в английском языке (deal — ди: л, deaf — дэф, great — грейт и т.д.).
                                            Но откуда взялась эта пошесть с «репозитАриями»? Снова же, обычный человек, увидев это слово впервые, скорее всего прочитает буква в букву «репозиторий». И хоть он будет не совсем прав (правильное произношение слова — рэ'пазитори, с ударением на второй слог), но будет гораздо ближе.
                                            И я был бы очень рад, если хоть один человек, прочитав этот комментарий, станет произносить эти слова верно.
                                              +4
                                              Возможно, они путают репозиторий с депозитарием.
                                                0
                                                Возможно, я не подумал об этом. Теперь я понимаю откуда ростут ноги у этого искажения, но тем не менее лучше произносить правильно, чем путать.
                                                0
                                                Ух, я как раз всегда говорил «хидер», надо же. Спасибо)
                                                  0
                                                  в копилку: энджайн вместо энджин (engine)
                                                  +3
                                                  Высший пилотаж произносить «сустем» и «экзишник»
                                                    0
                                                    Высший пилотаж — это читать по правилам французского или немецкого языка без запинок ;)
                                                      +3
                                                      Мой личный эталон — «канцель» («cancel»).
                                                        0
                                                        Я тоже так часто говорил, сейчас «по-русски» читаю как-то посередине между, т.е. «кансель».
                                                          0
                                                          У нас препод в универе говорила «цанцэл» :)
                                                            0
                                                            Сам всегда так же произношу :-)
                                                            Вообще, замечаю: если английское слово произнести по правилам чтения немецкого языка — его написание легче воспринять на слух, и меньше вероятность исказить его на письме. Особенно, когда собеседнику это слово незнакомо.
                                                              0
                                                              Во времена приставок Dendy одну из управляющих кнопок на джойстике некоторые деятели называли «Селест» («Select»).
                                                              0
                                                              У меня в институте преподаватель СИ говорил пьЮблик
                                                              0
                                                              В словарях есть оба варианта (с О и с А). И вообще, это устоявшийся программистский сленг. Если говорить по русски, то и «мерж», и «верифицировать», и «теги», и «лог», и «багтрекер», и «фикс», и «коммит» употреблять нельзя. И если я напишу всё на великорусском, коллеги будут читать мой пост в два раза дольше.
                                                                0
                                                                В некоторых (очень немногих) словарях действительно есть оба варианта, большинство других указывают исключительно вариант через О. Также Википедия и Гугл. Возможно, у произношения слова как «репозитарий» есть какое-то оправдание, но всё же лучше, как мне кажется, использовать общепринятый вариант. Мне лично оно уж совсем режет слух.
                                                                Те другие слова, что вы написали, я тоже использую каждый день. Это обычные кальки с английских слов, и это их большой плюс. Я совсем не за перевод всех терминов на русский, абсолютно наоборот — калькирование уменьшает различие между языками, позволяя людям разных национальностей проще общаться. У меня друг работает в Ubisoft и ему часто приходится сталкиваться с французской документацией или общаться с главным офисом — так вот, во французском практически все технические термины были переведены, и это ужасно — их все нужно учить с нуля.
                                                                Всё, что я хотел написать — это что калькировать нужно с сохранением исходного звучания, ну или хотя бы не додумывать своих звуков. Ведь еще существуют люди, которые произносят browser как «броузер».
                                                                  +3
                                                                  Это обычные кальки с английских слов

                                                                  Это не кальки, это заимствования. Калька — это поморфемный перевод, для приведённых слов кальками были бы «слияние», «проверять», «бирки», «летопись», «жукоотслеживатель», «крепление» и «посвящение» (:
                                                                0
                                                                Но откуда взялась эта пошесть с «репозитАриями»?

                                                                Пишу «репозиторий» — спеллчекер предлагает «депозитарий», соответственно думаю, что писать нужно «репозитарий» рассчитывая, что правило заимствования одно и тоже.
                                                                  0
                                                                  Мицголь?
                                                                    0
                                                                    Петросян-некропостер?
                                                                      0
                                                                      Тоже мне некропостер
                                                                    0
                                                                    Помойму, слово «репозитАрий» куда как старше всего этого нашего айти, оно означает «хранилище». Но интернеты пришли с айтишниками — понятно, почему в гуглопоиске слово репозитОрий ищется чаще. Гуглопоиск — не гарант исторической справедливости.
                                                                      0
                                                                      Спс, чувак. Узнал, что хедер, а не хидер
                                                                    +2
                                                                    Честно говоря, раскрашенные вершины совершенно не помогают понять, откуда взялась, например, ветка release: из master или temp. Если в Git делать обычные слияния из двух источников и продолжать только одну ветку (а зачем вам больше), то никакого различия нет. И аргумент про rebase в локальном репозитории какой-то надуманный…
                                                                      +1
                                                                      «Одомашненные приматы»
                                                                      Скорее всего речь о en.wikipedia.org/wiki/Code_monkey
                                                                        –2
                                                                        Git и Mercurial это одно и то же по сути, только у первого искаропки куча фич, которые в последнем надо включать в конфиге, вот и вся разница.

                                                                        Mercurial это казуальная версия Git, так сказать на пальцах.
                                                                          +1
                                                                          не все так просто )
                                                                            +1
                                                                            Зато научно популярно :)
                                                                            +1
                                                                            ничего, с возрастом вы научитесь ценить и результат, добытый без вывихивания мозга и чорной магии
                                                                              0
                                                                              Это вы про что?
                                                                            +7
                                                                            Можете ли вы мне сказать, на какую ветку было зафиксировано изменение ab3e2afd?

                                                                            for i in `git show-ref --heads --dereference --hash`; do
                                                                              if [ `git rev-list ab3e2afd ^$i | wc -l` -eq 0 ]; then
                                                                                echo "`git describe $i` includes the change ab3e2afd";
                                                                              fi;
                                                                            done
                                                                              +17
                                                                              интуитивно понятный интерфейс
                                                                                0
                                                                                Да уж. Сам до такого не додумаешься, только копипастить
                                                                                  0
                                                                                  Используйте SmartGit.
                                                                                    0
                                                                                    угу. «добавьте ещё один слой, в котором черти рисуют друг друга со спины» (это же касается и git).
                                                                                    для сравнения — hg log -r cset --template '{branch}\n'. при этом ВСЕ необходимые знания для того, чтобы составить эту команду, находятся в hg help. при этом ключ --template — чтобы вывести только имя ветки
                                                                                      0
                                                                                      жалко, что он платный.
                                                                                        0
                                                                                        «SmartGit can be used free of charge for non-commercial purposes.»
                                                                                        SmartGit бесплатен для некоммерческого использования.
                                                                                          0
                                                                                          К сожалению, я работаю над коммерческим софтом.
                                                                                      +4
                                                                                      git branch --contains <commit>
                                                                                        +1
                                                                                        это нужно было ответить сюда
                                                                                        и да, а почему вы мне это написали после того, как посоветовали использовать smartgit?
                                                                                          0
                                                                                          Это два разных подхода к решению одной задачи. Кому то консоль нравится, кому то удобнее графическое представление.
                                                                                      0
                                                                                      Надо сделать новую команду и закомитить в ветку git'а.
                                                                                      0
                                                                                      Ок. У меня есть три ветки: интеграционная, для выкладки на тестовые стенды, для выкладки в продакшин. 90% коммитов попадают во все три. Как прикажете красить?
                                                                                        +2
                                                                                        А какой у вас «воркфлоу»?
                                                                                        Вот у меня в HG всё понятно: сначала коммичу в свою ветку, затем в тестовую, а когда всё исправлено — в продакшн. Всё раскрашено как надо, логично.
                                                                                          0
                                                                                          Лабаем-Лабаем-Лабаем — Тестируем-Тестируем-Тестируем — Деплоим — Фиксим — Лабаем-…
                                                                                        +2
                                                                                        По-моему единственная проблема git — это сложность.
                                                                                        Начать действтвительно эффективно им пользоваться без старах выстрелить себе в ногу (и своим коллегам) можно только после того, как прочтешь хороший кусок документации и поймешь его архитектуру, которая, на мой взгляд, предельно осмысленная и в дополнениях уже не нуждается.
                                                                                          +5
                                                                                          > По-моему единственная проблема git — это сложность.

                                                                                          Git простой и предельно логичный в своей архитектуре. Сложности и магия возникли тогда, когда попытались сделать «как в свн», тут-то абстракции потекли.
                                                                                            +1
                                                                                            Магия возникает еще и при использовании чисто git'овых средств, вроде удаления ветки на удаленном репозитории или переключение веток при незакоммиченных изменениях. Как это работает не очень понятно, если не знать про index, working directory, bare репозитории, pull/fetch и тп.

                                                                                            То есть, чтобы просто не попротить все нужно знать как гит устроен. Это проблема. Вы же не изучаете устройство чайника, чтобы им пользоваться.
                                                                                              0
                                                                                              Ну-ну, не перегибайте. Рядовым девам нечего знать такие нюансы. Они себе код покомитили, а потом техлиду пул реквест отправили. А вот техлиду не знать разницы между bare и обычным репозиторием как-то уже нехорошо.
                                                                                              +3
                                                                                              Сложности и магия возникли тогда, когда попытались сделать «как в свн»
                                                                                              сложность и магия возникает тогда, когда пытаешься осмысленно сделать хоть что-нибудь сложнее git add/rm && git commit; git push origin master; git pull origin master. Неоправданная сложность начинается с первых шагов (элементарный пример): зачем командам pull/push нужно сообщать что и куда/откуда мы льём и почему недостаточно просто push/pull (в hg этого достаточно)?
                                                                                              не говоря про то, что с одной стороны подпирают мегабайты мануалов, которые ты, @#$%, будешь читать, чтобы понять даже что, собственно, спрашивать у людей в интернетах. с другой стороны — нащальника, который мягко намекает на то, что пора бы и работу работать, а не только маны раскуривать (а если сделать как попало — следующим шагом будет обмен патчами по почте).
                                                                                              И да — что же к такому простому и понятному инструменту пишут обёртки вроде git-flow, а?
                                                                                                +4
                                                                                                у тебя в конфигах косяк

                                                                                                branch..remote
                                                                                                When in branch, it tells git fetch and git push which remote to fetch from/push to. It defaults to origin if no remote is configured. origin is also used if you are not on any branch.

                                                                                                выполни: git config branch.master.remote origin
                                                                                                  +7
                                                                                                  Опять всё интуитивно понятно, да?
                                                                                                  +2
                                                                                                  почему недостаточно просто push/pull (в hg этого достаточно)


                                                                                                  Из репа созданного hg init — недостаточно. А из склонированного репа git тоже умеет pull/push без лишних слов.

                                                                                                  Вообще моё впечатление такое, что у пользователей меркуриала проблемы с пониманием концепции staging area.
                                                                                                    +1
                                                                                                    а тем не менее в первом попавшемся гайде «git для полных идиотов» push/pull выглядят именно так, как я показал: help.github.com/fork-a-repo/#_more_things_you_can_do
                                                                                                      +1
                                                                                                      у пользователей меркуриала проблемы с пониманием концепции staging area
                                                                                                      если это вы лично обо мне, то вынужден расстроить — я переехал на hg уже после того, как попользовался git с полгода. и концепцию staging area усвоил.
                                                                                                      и да, staging area — это кастрированные managed queues.
                                                                                                        0
                                                                                                        если это вы лично обо мне

                                                                                                        Боже упаси, я вас первый раз вижу (:

                                                                                                        staging area — это кастрированные managed queues.

                                                                                                        managed queues как вы их назвали, это quilt приделанный на скотче к меркуриалу.
                                                                                                        А staging area — это средство отделения мух от котлет — всех изменений в воркдире от изменений с которыми мы собираемся сейчас что-то сделать.
                                                                                                  0
                                                                                                  Ну и выстрелишь себе в ногу, и что? Откатишь назад. Запороть что-то необратимо случайно — очень маловероятно, для опасных операций надо всякий --force писать, т.е. это делается очень редко и 7 раз подумав и сделав резервную копию.

                                                                                                  git чуть-чуть сложнее в освоении, чем, скажем, svn, но невероятно проще в жизни.
                                                                                                    0
                                                                                                    Я как-то набрал в консоли git checkout и случайно ткнул Enter, не дописав имя файла. Результат был прямо протвоположен вашему комментарию: пять часов по восстановлению того, что было потеряно безо всякого предупреждения.
                                                                                                  –3
                                                                                                  Ой, а в mercurial уже есть аналоги git add -p, git rebase -i и git reflog?
                                                                                                    +2
                                                                                                    add -p всю жизнь был hg record, reflog тоже есть, причем reflog интегрирован в битбакет (форма поиска по репозиторию умеет его синтаксис), rebase не пользуюсь, не знаю, может и нет
                                                                                                      +1
                                                                                                      > add -p всю жизнь был hg record, reflog тоже есть, причем reflog интегрирован в битбакет (форма поиска по репозиторию умеет его синтаксис),

                                                                                                      а, ну отлично.

                                                                                                      > rebase не пользуюсь, не знаю, может и нет

                                                                                                      Это такая интерактивная переписывалка истории.
                                                                                                      0
                                                                                                      и rebase с cherry-pick сто лет как в дистрибутиве
                                                                                                        0
                                                                                                        А ваш hg rebase ханки редактировать умеет, как git add -p / -i
                                                                                                          0
                                                                                                          Тьфу, hg record имел в виду. Вижу что вроде нет, минимальная единица редактирования коммита — один ханк. А мельче можно? У git add -p есть среди вариантов 'e', который вызывает $EDITOR в котором ханк-кандидат можно FUBAR отредактировать как нужно.
                                                                                                            0
                                                                                                            ну да, нет такого. приходится отменять коммит и править исходник.
                                                                                                            а вот правда, что в git можно разбивать ханки на несколько? на случай, если исправили вот в строке два слова, а закомитить сейчас нужно только одно. это — фича, которой в hg и расширениях действительно не хватает.
                                                                                                              0
                                                                                                              Да, можно. Используется через интерактивный режим добавления
                                                                                                              git add -i
                                                                                                                0
                                                                                                                … а также через add -p.
                                                                                                                Да, строки ханка можно отредактировать при добавлении как надо. Т.е., например, второе слово вернуть как было. При следующем добавлении будет дифф того что уже в staging/закоммичено и в рабочем каталоге.
                                                                                                                  0
                                                                                                                  А Вы встречали графический клиент, который позволяет такое делать (желательно под линукс)?
                                                                                                                    0
                                                                                                                    Не встречал, работаю исключительно из консоли.
                                                                                                                    Может EDITOR=gvim?
                                                                                                          0
                                                                                                          rebase есть.
                                                                                                          +3
                                                                                                          Очень надуманно… у нас в день валится пара десятков изменений в ветках, которые частично уходят на продакшн, частично на текущий релиз… Если вы наворотили делов, напишите гайд по веткам на страничку, и уже завтра все будет выглядеть идеально. Цветная раскраска, и что? GitX, GitGui тоже раскрашивают ветки.
                                                                                                            +1
                                                                                                            Это всё очень религиозно. Наша команда, например, разделилась на две части — одна говорит, что гит — непонятная поделка, другая же, что меркуриал. И у всех есть свои основания так говорить. Не надо ничего сравнивать, нужно использовать то, что нравится для своих проектов и то, что придётся для проектов, где вы не решаете таких вопросов или их даже не надо решать (сложность переезда, невозможность выделения времени на это и т.п.)
                                                                                                              +2
                                                                                                              Использовать два во многом аналогичных инструмента для не основной деятельности может выйти накладно и просто неудобно. А учитывая что почему-то гитхаб более популярен чем битбаккет, то чуть ли не становишь вынужден использовать гит хотя нравится меркуриал.
                                                                                                                0
                                                                                                                Не вижу никаких неудобств отчего-то. Это то же самое, что у каждой команды есть свой code style, в одной пишите один код, в другой другой, а сами третий
                                                                                                              +6
                                                                                                              Не очень понимаю комментаторов.
                                                                                                              Ключевое различие git и mercurial — это подход к слиянию веток. В mercurial нельзя несколько веток слить в одном коммите и это очень правильно! Никакой путаницы, всё под контролем, всё последовательно. А после мегамёрджа в git никто ничего никогда уже не разберёт.
                                                                                                                +6
                                                                                                                И да, в git нет человечной поддержки разграничения прав доступа к репозиторию. В HG — из коробки, за 10 минут всё гуглится и настраивается.
                                                                                                                  +1
                                                                                                                  да не нужно там ничего гуглить. acl есть в коробке, а для минихостинга есть mercurial-server
                                                                                                                    0
                                                                                                                    Я имел в виду гугление доков и примеров )
                                                                                                                      +1
                                                                                                                      всё есть в коробке — hg help acl и man mercurial-server
                                                                                                                +2
                                                                                                                Засранцы, Линус ждет ваших патчей мердж реквестов.
                                                                                                                  +1
                                                                                                                  как раз линуса всё устраивает. лучше сделайте CLI фронтенд к libgit2
                                                                                                                  0
                                                                                                                  Появился интересный ответ на оригинальную статью — felipec.wordpress.com/2012/05/26/no-mercurial-branches-are-still-not-better-than-git-ones-response-to-jhws-more-on-mercurial-vs-git-with-graphs/
                                                                                                                    0
                                                                                                                    Немного не удобно пользоваться git name-rev для каждой ревизии, поэтому я написал свой хук, который автоматически добавляет в коммит мессадж информацию о названии ветки и её описании (если доступно). Сохранил в файле .git/commit-msg:

                                                                                                                    #!/bin/sh
                                                                                                                    #
                                                                                                                    # Automatically adds branch name and branch description to every commit message.
                                                                                                                    #
                                                                                                                    NAME=$(git branch | grep '*' | sed 's/* //')
                                                                                                                    DESCRIPTION=$(git config branch."$NAME".description)

                                                                                                                    echo "$NAME"': '$(cat "$1") > "$1"
                                                                                                                    if [ -n "$DESCRIPTION" ]
                                                                                                                    then
                                                                                                                    echo "" >> "$1"
                                                                                                                    echo $DESCRIPTION >> "$1"
                                                                                                                    fi

                                                                                                                    Прошу прощения, что без форматирования — не достаточно кармы, очевидно…
                                                                                                                    +1
                                                                                                                    Не смог остаться равнодушным.

                                                                                                                    Честно говоря, не нравятся обе ваши картинки. На мой взгляд, такого допускать не стоит ни в какой системе.
                                                                                                                    И то, в какой ветке было сделано какое-то изменение не имеет смысла. Имеет смысл то, в какой ветке есть это изменение, а в каких — нет.

                                                                                                                    Есть ощущение, что Mercurial круче и гибче, но из поста так и не смог вкурить чем же именно.
                                                                                                                    Как это часто бывает, пересев с Svn на Git испытал чувство экстаза. Все, что работало плохо и часто ломалось в Svn в Git просто великолепно реализовано. И сам процесс разработки с переездом на Git сразу сдвинулся с места. Конечно, ограничения ощущаешь лишь со временем, но до сих пор Git позволяет мне вести процесс разработки так, как мне нужно и удобно.

                                                                                                                    Возможно так и надо подходить к вопросу — если встают непреодолимые препятствия или существенные ограничения, то да, пора «менять кобылу». Но пока она везет и достаточно резво, какой резон пересаживаться на другую? Мне кажется в этом основная причина того, что Git — мэйнстрим. Он достаточно хорош, чтобы его использовать, а его ограничения не настолько критичны, чтобы переводить с него процесс на mercurial, в котором, кончено же, со временем тоже почувствуются свои ограничения.

                                                                                                                    Git очень гибок и в этом его минус, если не умеешь им пользоваться. Он дает огромное количество инструментов и надо их изучать.
                                                                                                                    Сейчас наш workflow построен так, что я точно знаю, где и когда было сделано то или иное изменение и когда оно выйдет в свет.
                                                                                                                    История проста и понятна и по ней я могу точно сказать, где именно был сделан тот или иной коммит и когда он попал в ту или иную ветку. Это видно по истории. Это в git решается не на уровне самой системы, а на уровне организации процесса. По крайней мере, у меня так.
                                                                                                                      0
                                                                                                                      Я пользовался долгое время и тем и другим. Принципиальной разницы не заметил. Декоративная разница есть, но не более того.

                                                                                                                      Хотя нет — есть разница при поведении в очень сложных ситуациях, которые сами по себе являются не допустимыми при коллективной работе. Но, с учетом того, что эти ситуации относительно редки, разница получается минимальной.
                                                                                                                        0
                                                                                                                        если вам графики цветные строить то до, пользуйтесь этим
                                                                                                                        а если работать, то всё таки git

                                                                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                                        Самое читаемое