> Давайте тогда уже вспомним, что команда commit в гите существовала не всегда

Да, давай вспомним -  существовала с первых месяцев разработки, это конец 2005-го. Модульный пц в hg, который я описываю выше, был как минимум до 2011 и всё ещё присутствует в некотором виде.

> Или что в 2016 году у каждого пользователя гита свой собственный набор алиасов различной степени кривости.

Это твои фантазии. У каждого пользователя в лучшем случае пара алиасов для git log под свой вкус, в общем как и у пользователей hg.

> Хотя что это я — ведь это же Совершенно Другое Дело, потому что это же целый Гит Освящённый Сиянием Святого Торвольца.

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

> Как бы вопрос умолчаний: самое главное — версионировать исходники — hg умеет без никаких плагинов.

У человека что самое главное? Пусть будет голова - ей он иногда думает и регулярно кушает в неё. Но если отделить голову от остального тела, то останется ли от неё прок? Едва ли.

С SCM ситуация точно такая же - движок это хорошо, но консистентность и удобство интерфейса к нему имеют не меньшее значение. Тем более внутренности hg сами по себе не уникальны и не представляют никакого интереса вне mercurial'а.

Тебя, кстати, не напрягает, что с тобой приходится нянчиться как с ребёнком и разжёвывать очевидные взрослым людям вещи?

> А может ли быть так, что это как раз git rebase — гибрид ужа с ежом, запихивание в одну команду собственно rebase и переупорядочивание коммитов

Если присмотреться к {rebase, mq, histedit}, то можно увидеть что все они внутри делают примерно одно и тоже, т.е. имеет место быть размножение реализации функционала. В частности histedit это тот же самый rebase с бОльшим кол-вом настроек. И mq тоже ребейз, но основанный на другой элементной базе (не на кишках hg .. почему собственно его хотят и хернуть из ртути).

В общем, rebase архитектурно является одной компонентой, а не тремя. И, ктобы мог подумать, интерфейсно эту компоненту тоже удобно представлять одной командой т.к. опции для разных сценариев применения rebase взаимодополняющие, а не исключающие друг друга.

> Да, сколько?

Опять в немощного будем играть? Посмотри сам в вики hg - их на порядки больше официальных.

> Это, конечно же, враньё. Ветки были всегда ...

Отлично, но речи не было что когда-то mercurial был совсем без веток...

> просто без ограничений как в гите (какой ужас! да как они посмели!).

В Git у веток никаких ограничений нет, так сказать легковесные ветки в терминологии hg. А на стандартные ветки mercurial как раз наложены некоторые существенные ограничения...

> Потом запилился плагин bookmarks с гитоподобными ветками, потом его положили в дистрибутив, потом вмержили в ядро

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

> Во-первых, никто, кроме SemanticMerge и аналогов такое не разрулит.

Ничто не умеет так делать кроме того что умеет? Ну как бы да, с такой бессодержательной тавтологией не посморишь. Чтобы ты себе там не представлял о данной фичи, но в git она есть практически изначально .. а всё почему? git - the stupid _content tracker_.

> Во-вторых, вот не будут имена файлов нести семантической нагрузки — тогда и поговорим.

У тебя hg log и hg annotate научились понимать семантический смысл имён файлов? Ну чтож .. остаётся только порадоваться за дурь которой ты долбишься. Но в любом случае не понятно как такая замечательная фича подскажет annotate'у кем был сделан 7500 ра перемещённый кусок кода.

> у вас в гите «история» зависит от ключей команды diff и количества изменений

Примерно так и есть, это вполне логично - с учётом отслеживания перемещения кода история является субъективным понятием. Есть несколько точек зрения (алгоритмов) её построения и методы визуализации.

> diff --git умеет записывать перемещение/копирование файлов, но при импорте в git эта информация теряется

Как уже не тружно было догадаться, git это _content tracker_, а не _file tracker_, потому для него не существует понятия перемещения файла на уровне хранилища. Всё что diff показывает с перемещениями это эвристика предназначенная для пользователя, а не для другого git'а.

> Враньё: версионировать исходники.

Этот вопорс уже был разобран выше в секции 'SCM для детей дошкольного возраста'. Кратко, версионирование является функционалом библиотеки (движка) версионирования, а не DVCS.

> Враньё как минимум в количестве и качестве extension points.

В этом кроется ещё одно заблуждение чрезвычайно глупых людей которое выражается в вере в серебрянную пулю, или в существование очень простого решения сложной задачи. Разработчики hg приняли за такое решение твои extension points решив совсем отстраниться от дизайна консистентности и полноты функционала.

Но чудес не бывает, сложные задачи сами собой не решаются и вся история разработки mercurial достаточно красочно иллюстрирует это. Собственно, с этого я и начал текст выше.\

> да-да, вот только караван всё идёт почему-то. Вероятно потому, что на стороне hg про поединок и не в курсе.

Идущие на смерть приветствуют императора, альтернатив то у них всё равно нет.