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

не commit, так rm или annotate — несущественно (публичная история гита начинается с big tools rename в 2005).

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

ага, гугл по запросу "git aliases", следует понимать, тоже фантазирует:

* "The Ultimate Git Alias Setup · GitHub" https://gist.github.com/mwhite/6887990
* Must Have Git Aliases: Advanced Examples - Be Present Now http://durdn.com/blog/2012/11/22/must-have-git-aliases-advan.../
* lab 11 Aliases - Git Immersion http://gitimmersion.com/lab_11.html

Впрочем, лучше будет предоставить слово счастливым пользователям: https://github.com/search?utf8=%E2%9C%93&q=al... (134К результатов)

Попытки этот разброд и шатание упорядочить святым апстримом, естественно, игнорируются.

>> Как бы вопрос умолчаний: самое главное — версионировать исходники — hg умеет без никаких плагинов.
> У человека что самое главное? Пусть будет голова - ей он иногда думает и регулярно кушает в неё. Но если отделить голову от остального тела, то останется ли от неё прок? Едва ли.

Обожаю некорректные аналогии.

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

Хм, обычно «консистентность» и «удобство» в тредах за гит являются ругательством. Это, в принципе, понятно — исторически сложилось так, что нужно и полезно только и исключительно то, что в гите есть, а ненужно и вредно всё остальное. Соответственно, когда в гит притаскивают то, что в нём изначально отсутствовало, оно перестаёт быть ненужным и вредным и автоматически становится нужным и полезным.

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

А, так это вы хамить мне пытаетесь? Вам идёт. Но пробуйте тяжелее.

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

mq работает с очередью патчей и показывает их как виртуальные changesets; rebase перемещает кусок графа версий; histedit манипулирует (переставить/удалить/поправить) changesetами из заданного диапазона. Как-то слишком приблизительно «одно и то же». Код под капотом может быть сколько угодно похож, но непонятно, почему это должно хоть сколько волновать пользователя.

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

Проверочный вопрос — является ли «interactive "rebase"» неотъемлемой частью обычного rebase? Нет. Значит, histedit отдельно, а rebase отдельно.

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

А я что, «бремя доказательства лежит на утверждающем». Олсо «на порядки» — это сколько именно?

>> просто без ограничений как в гите (какой ужас! да как они посмели!).
> В Git у веток никаких ограничений нет, так сказать легковесные ветки в терминологии hg.

Конечно же, это не так. На каждую вершину графа версий репозитория должна ссылаться какая-нибудь ref, иначе git gc эту голову удалит. в hg же можно безопасно ветвиться от любой точки в истории, т.к. hg не решает за пользователя, какие изменения у него считать мусором, а какие — нет.

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

Ух ты, живой телепат! Мало что мысли в реальном времени читает, так ещё и доступ к архиву имеет!

Вот подробный тред про «неправильное» ветвление в mercurial: https://news.ycombinator.com/item?id=11672259 (TL;DR hg branch действительно не годятся для feature branches, но отлично годятся для ongoing line of development; до bookmarks "feature branches" были просто ещё одной головой DAG версий, после — им стало можно давать имена, как в гите, ура, револю… а нет, показалось)

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

git-log -L <start>,<end>:<file> штоле? Не отрицаю полезности, однако, [2013](https://github.com/git/git/commit/12da1d1f6ffcd546a892a33302...) при всём желании не тянет на «с самого начала».

Также в реальном мире нередко правят содержимое файла *одновременно* с его перемещением/копированием, и вот тут-то «тщательно выверенная» (ака «само выросло») абстракция протекает: гит начинает пытаться угадать (а при достаточном большом количестве различий — даже не начинает, просто делает вид, что старый файл удалили, а новый создали с ноля), что в куда переименовалось/скопировалось.

>> Во-вторых, вот не будут имена файлов нести семантической нагрузки — тогда и поговорим.
> У тебя hg log и hg annotate научились понимать семантический смысл имён файлов?

Переформулирую: вот не будет разницы, как называется файл, в котором лежит трекаемый текст — тогда и поговорим. А пока что у вас абстракция по-прежнему течёт.

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

Эвристика, если diff этот экспортирован из Git и файл был изменён и скопирован/перемещён. К счастью, возможность импорта/экспорта из/в diff --git не является прерогативой Git.

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

Это точно. Ведь git не является полноценной альтернативой Mercurial.