Pull to refresh

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

Git *Version control systems *Mercurial *
Translation
Original author: J. H. Woodyatt
Некоторое время назад я опубликовал очень многословное сочинение, где пытался объяснить, почему 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] Одомашненные приматы — вероятно, отсылка к Тимоти Лири или Роберту Антону Уилсону — прим. перев.
Tags:
Hubs:
Total votes 103: ↑87 and ↓16 +71
Views 59K
Comments Comments 130