>> Ещё понимаю переход hg->git, но обратный.. не разумею ... попробовал hg и втянулся ... очень приятно ... продуманно. Как в питоне
> Например, изначально hg был модульным так, что без мозготраха нельзя было даже зажечь цвета в diff - нужно было готовить модуль и делать специальный алиас с другим названием команды (лол ... цвета для diff так и остались модулем color, только теперь не нужно делать алиас для команды). Давайте тогда уже вспомним, что команда commit в гите существовала не всегда. Или что в 2016 году у каждого пользователя гита свой собственный набор алиасов различной степени кривости. Хотя что это я — ведь это же Совершенно Другое Дело, потому что это же целый Гит Освящённый Сиянием Святого Торвольца.
> Время шло и мало-помалу до идиотов доходило, что с такой модульностью жить нельзя. Но полностью спрятать атавизм под капот ума опять таки не хватило .. на текущий день все основные модули поставляются с mercurial, но фичи всё равно нужно явно включать в конфиге.
Как бы вопрос умолчаний: самое главное — версионировать исходники — hg умеет без никаких плагинов.
> Кроме этого неверно выбранная стратегия разработки, т.е. попытка отстраниться от дизайна фич приложения через модули, привела к пересечению функционала в разных модулях. Например, чтобы получить функционал git-овго rebase в mercurial нужно сразу три модуля - rebase, mq и histedit .. и даже с ними не получается полного функционала и удобного к нему интерфейса.
А может ли быть так, что это как раз git rebase — гибрид ужа с ежом, запихивание в одну команду собственно rebase и переупорядочивание коммитов… /* philosoraptor.jpg */ Да нет, глупости какие, разработчики Git не могут ошибаться.
> А сколько ещё есть экспериментальных модулей делающих одно и тоже...
Да, сколько?
> Аналогичная ситуация случилась с ветками - их нагородили несколько видов с разными свойствами и умудрились привязать сами коммиты к некоторым типам веток. В общем, снова люди решали проблемы которых на самом деле не было, сделали overengineering.
Это, конечно же, враньё. Ветки были всегда, просто без ограничений как в гите (какой ужас! да как они посмели!). Потом запилился плагин bookmarks с гитоподобными ветками, потом его положили в дистрибутив, потом вмержили в ядро. Ну да, хорошая годная функциональность, бывает.
> Есть ещё комичные примерны дизайна в этой убогой vcs, прямо в новости пишут:
>> Добавлено экспериментальное расширение automv, которое автоматизирует определение фактов переименования и копирования файлов в репозитории ...
> VCS, ориентированная на работу исходниками, всё ещё оперирует понятиями перемещения файла, а не кусков текста. Раньше если как-то не так перемещаешь файл (не через hg mv), то ртуть теряет его историю .. а теперь вот впилили костыль, но всё равно hg не разрулит разрез файла на несколько, склейку файлов в один или суперпозицию этих изменений. Всё это нужно для нормальной истории и blame/annotate.
Во-первых, никто, кроме SemanticMerge и аналогов такое не разрулит. Во-вторых, вот не будут имена файлов нести семантической нагрузки — тогда и поговорим.
К вопросу о комичных эпизодах:
* у вас в гите «история» зависит от ключей команды diff и количества изменений
* diff --git умеет записывать перемещение/копирование файлов, но при импорте в git эта информация теряется
Нет-нет, я всё понимаю — это Соверщенно Другое Дело.
> В итоге hg не имеет консистентного стабильного функционала
Враньё: версионировать исходники.
> имеет меньшую гибкость по сравнению с прямым конкуретном.
Враньё как минимум в количестве и качестве extension points.
> В этом поединке hg ушло в историю вполне заслуженно.
да-да, вот только караван всё идёт почему-то. Вероятно потому, что на стороне hg про поединок и не в курсе.
