Здравствуйте, alex_public, Вы писали:

_>Ну как видишь никаких ограничений нет на самом деле (и я кстати об этом говорил изначально). Есть только разница в удобстве (причём в пользу Mercurial). Люди даже подобные https://www.mercurial-scm.org/wiki/GitConcepts#Command_equivalence_table таблички соответствия команд делают. ))) Но опять же там есть не все команды (например нет heads) из-за отсутствия в конкуренте соответствующей концепции (типа анонимных веток).

Вот тут на родственном форуме (если ты в РФ, то без Tor не прочтёшь) коллега Lyubomyr Shaydariv пишет (месяца 3 назад, так что актуально):

Я справді дуже люблю hg, і для своїх особистих проектів надаю йому перевагу, а не git, проте з часом я маю все ж деякі розчарування стосовно нього. З ходу можу назвати наступне:

* Відсутність staging area. В git її наповнювати можна в імперативній формі, і згодом видалити із неї файли, випадково туди занесені. Писати hg commit із складним фільтром для комміта важко, і виправляти такий комміт незручно або важко (як і через hg commit —amend, так і через hg strip —keep).
* Імена гілок у hg вічні. Якщо планується якась експериментальна гілка, яку планується назвати «experimental», дуже бажано подумати ще раз, чи вартує їй давати саме таке ім’я, оскільки навіть з hg commit —close-branch створити нову гілку із таким іменем більше не можна буде. Ніколи. Навіть через два роки. Смішно, але тут навіть svn ліпше виглядає.
* Закладки (bookmarks), які концептуально трохи ближчі до git-ових гілок, в hg випиляти інколи також складно (якщо можливо).
* Субрепозиторії в hg мені особисто здаються «дикішими» за субмодулі в git, оскільки hg при коміті в батьківському репозиторії оновляє .hgsubstate, якщо, знову ж таки, в hg commit не вказати правильний фільтр.
* .hgignore лише, по ходу, в кореневій директорії. Якщо субдиректорії мігрують з місця на місце з часом, це також означає, що шляхи в одному .hgignore також потрібно поправити вручну.

Заметь, человек для себя предпочитает Hg, но его подобные грабли таки достали. Я до такой глубины ещё даже первично не докопался.

_>Ну и зря. Если лично тебе оно не нужно, то это не значит что и другим тоже. Я знаю многих использующих Mercurial вообще без named branches/bookmarks и при этом очень довольных удобством работы.

Это несекьюрно, годится только для персонального репо, который ни с кем не обменивается.
Лучше это было бы перенести в extensions и не включать по умолчанию.

_>Ох, ну я же ещё в самом начале этой дискуссии писал, что за годы параллельного развития все современные dcvs обрели приблизительно одинаковые технические возможности (ну вот разве что git так и не научился по нормальному анонимным веткам) и выбор должен делаться только по удобству (достаточно субъективная вещь) их использования. Ну если хочешь, можем разобрать по пунктам. )

Ну да, теперь осталось сделать совсем немного мелочей:
1. Внести такие действительно полезные вещи, как shelve, record, histedit, rebase в базовую функциональность, а не расширения.
2. Диверсии в виде неименованных голов, наоборот, вынести в расширения и не включать по умолчанию.
3. Описанным расширениям довести функциональность до минимально необходимого набора:
* показ staging, сброс staging в ноль, частичный сброс (по файлу, по диффу).
* shelve должен уметь брать не только локальные изменения, но и staging.
4. Решить остальные описанные Lyubomyr Shaydariv проблемы. Для начала, переименовать таки "ветки" во что-то другое (покопался в словаре, нашёл замечательное слово tally). Далее, обеспечить возможность их делать неуникальными (а лучше вообще не опираться на "закрытие", эта концепция должна умереть). Решить остальные описанные им проблемы.

_>В Mercurial это тоже реализовано, через команду hg histedit. Однако я крайне не рекомендую использовать этот подход, т.к. правильным методом review в DCVS должно быть создание новой ревизии.

Я проверил — histedit меняет хэш ревизии, так что тут, похоже, сделано адекватно (как в Git, Monotone и прочих, где хэш гарантированно требуется проверяемым по содержанию конкретной ревизии). А вот то, что ты этого не знаешь, и то, что я про histedit вытащил только после долгой дискуссии, показывает, что твой опыт просто неприменим под мои задачи и подходы.

_>Кстати, решение конфликтов — это должен был бы быть ещё отдельный пункт (ж — это же у тебя про экспорт/импорт). Но думаю там особых отличий нет, хотя алгоритмы и совсем разные. А вот что касается экспорт/импорта, то как раз тут у Mercurial всё намного проще и удобнее.

Опять пустые эмоциональные заклинания.

_>Тут и наличие анонимных веток и их поведение при синхронизации (они просто все возникают у всех)

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

_>Это от непривычки. ) А потом оказывается, что это ещё и намного удобнее старых подходов.

Не-а.

_>Я вот здесь http://rsdn.ru/forum/flame.comp/6338865.1

Автор: alex_public
Дата: 06.02.16

приводил картинку того, что имею в виду. Предположим что ревизии 2 и 3 созданы на разных компьютерах. Как бы ты реализовал подобное с помощью git? )

Очевидно — fetch+merge. Если ты хочешь сказать, что тебя утомляет необходимость назвать принятую от другого ветку, то я могу только выразить соболезнования, но не согласиться.