git vs mercurial (было "vcs vs vcs")

[watashiwa_daredeska]

насколько я понимаю, эти хеши служат для различения коммитов внутри репозитория.

Нет, это глобальные идентификаторы, такие же, как в git, если я правильно понял документацию. Т.е. если кто-то склонировал мой реп и что-то там поделал, кто-то ещё склонировал, поделал и т.д. и в конце концов я сам в какой-то момент решил вытянуть изменения себе, то по этим id я могу совершенно точно сказать, какие ченджсеты у меня уже есть и мержить их не надо (точнее, сам hg это определит).

И я не думаю, что злоумышленник сможет создать ветку с трояном в вашем репозитории, а потом обманом заставит вас включить её в релиз...

Я не говорил про мой репозиторий. Я говорил про что-то вроде github. Если его вдруг взломают и подменят содержимое там. С git всё довольно просто, я сообщаю хэш коммита и тот, кто качает с github, может быть уверен, что это ровно то же самое, что и в моём собственном локальном репозитории.

А вот перехватить бандл по дороге, поменять его, и отправить дальше - не получится. Там уже 256 бит в хеше.

Да пусть хоть миллион битов, какая разница? Злоумышленник сгенерит новый хеш, этот хеш будет вполне соответствовать контенту. Поймать можно только если другая сторона знает, какой хеш должен быть, если другая сторона знает только 48 бит, то при подделке контента надо соблюсти лишь чтобы эти 48 бит остались неизменны. В git видны все 256 бит, и передам я все эти 256 бит, поэтому соблюсти надо совпадение всех 256 бит хеша при подделке контента.

Однако, разве наличие доступа на запись и чтение не делает-ли бессмысленным подделку хеша?

Не делает. git проверяет консистентность постоянно. Если я просто где-то что-то поменяю вручную в .git/objects, то git будет ругаться, значит при изменении надо перегенерить все tree и commit объекты с их хешами и надеяться, что я не записываю хеш HEAD'а каждый вечер на бумажку :)

[watashiwa_daredeska]

я пока понял, как грамотно работать с гитовскими ветками, чуть голову не сломал. Да и то, читая сейчас сравнения, понял, что тогда я этого так и не понял.

В mercurial между тем, как я начал вообще читать о понятии ветки и тем, как успешно работал уже и с именованными, и с безымянными ветками, прошло меньше часа. Не говоря уже о том, что голову напрягать мне за это время даже чуточку не пришлось.

Странно. Я гитовские ветки понял с одного прочтения Git User's Manual по диагонали и тут же начал работать с ними. Видимо, зависит от какого-то склада мышления. Мне, например, git'овая документация кажется очень хорошей и понятной, а mercurial'овская — наоборот.

[drBatty]

Т.е. если кто-то склонировал мой реп и что-то там поделал, кто-то ещё склонировал, поделал и т.д. и в конце концов я сам в какой-то момент решил вытянуть изменения себе, то по этим id я могу совершенно точно сказать, какие ченджсеты у меня уже есть и мержить их не надо (точнее, сам hg это определит).

не по этим. эти сокращённые для людей.
вот вам полные:

Код: Выделить всё

drb@localhost:~/scripts$ hg glog -r tip
@  changeset:   21:d48d9a695a1c
|  tag:         tip
|  user:        drBatty emulek <666@gmail.com>
|  date:        Tue Apr 20 18:10:46 2010 +0400
|
drb@localhost:~/scripts$ hg glog -r tip --debug
@  changeset:   21:d48d9a695a1c5847ba084535a85a3cc10eba50aa
|  tag:         tip
|  parent:      20:05db351cb71a49d44ffe7da9554823f3b173616a
|  parent:      -1:0000000000000000000000000000000000000000
|  manifest:    21:e514dfe33b749abfa4b33bd80dfba6648f992f70
|  user:        drBatty emulek <666@gmail.com>
|  date:        Tue Apr 20 18:10:46 2010 +0400

Поймать можно только если другая сторона знает, какой хеш должен быть, если другая сторона знает только 48 бит

согласен. но... хеш тут из 256и бит.

[sash-kan]

Думаю, ты не будешь, спорить, что многое в этих двух системах реализовано по-разному.

нет конечно. в частности, та самая коммит- а не файл-ориентированность git-а — это уже очень и очень существенное отличие. прямо-таки ключевое.

Да, существенное. Но будешь ли ты утверждать, что оно однозначно положтельное? На мой взгляд, очень на любителя.

нет, ключевое. оно является составным элементом простоты архитектуры. оно упрощает работу с ветками/другими репозиториями.

[t.t]

насчёт именованых ветвей. Начиная с 1.2 есть hg ci --close-branch. Начиная (по-моему) с 1.5 есть hg branch --clean. Так что теперь они точно не постоянные.

Тогда тем более непонятно, нафига их прокачивать из репозитория в репозиторий.
Гипотетическая ситуация.
Допустим, в центральном репозитории бранч 'linux-2.6.30' (не знаю я, как они там зовутся), я клонирую и делаю локальный для нашей команды репозиторий, в котором мы работаем над адаптацией ядра для нескольких наших девайсов. Я делаю бранчи 'model1', 'model2' и т.д. Нам пофиг, какая там версия. Назавтра для какой-то модели решим переползти на 'linux-2.6.32' из центрального репозитория, смержимся и переползём. Нафига нам эти их ветки 'linux-*'? Тем более, если вдруг, налажен двунаправленный pull, наши бранчи им тоже не пришей кобыле хвост, им нужен будет только какой-нибудь 'public-2.6.32'.

Так они не для этого. Вообще мне описанная тобой ситуация не очень понятна. Точнее, не очень понятно, чего ты хочешь. Локальные имена, которые вообще не будут никуда пушиться? Для этого есть local tags и bookmarks. Или ты хочешь их пушить внутри команды, но не отдавать наружу? Тогда объясни своими словами, как это реализовано в git -- я попробую "перевести".

[t.t]

я пока понял, как грамотно работать с гитовскими ветками, чуть голову не сломал. Да и то, читая сейчас сравнения, понял, что тогда я этого так и не понял.

В mercurial между тем, как я начал вообще читать о понятии ветки и тем, как успешно работал уже и с именованными, и с безымянными ветками, прошло меньше часа. Не говоря уже о том, что голову напрягать мне за это время даже чуточку не пришлось.

Странно. Я гитовские ветки понял с одного прочтения Git User's Manual по диагонали и тут же начал работать с ними. Видимо, зависит от какого-то склада мышления. Мне, например, git'овая документация кажется очень хорошей и понятной, а mercurial'овская — наоборот.

Да, зависит. На мой взгляд, это примерно как vim vs emacs, только в другой плоскости. Вот я в виме работать могу; но комфортно себя при этом чувствовать -- ну никак, сколько раз ни пробовал. Мозги чуток набекрень становятся. И с гитом то же самое. А емакс и меркуриал -- как-то даже интуитивно всё само собой получается.

[t.t]

Думаю, ты не будешь, спорить, что многое в этих двух системах реализовано по-разному.

нет конечно. в частности, та самая коммит- а не файл-ориентированность git-а — это уже очень и очень существенное отличие. прямо-таки ключевое.

Да, существенное. Но будешь ли ты утверждать, что оно однозначно положтельное? На мой взгляд, очень на любителя.

нет, ключевое. оно является составным элементом простоты архитектуры. оно упрощает работу с ветками/другими репозиториями.

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

[t.t]

Кстати, в продолжение разговора о безымянных ветках: mercurial (hg)

[sash-kan]

и что именно под «игнорами» понимается?

Список игнорируемых файлов.

паттерны для игнорирования можно хранить в $GIT_DIR/info/exclude и .gitignore
второй из них — без проблем добавляется в репозиторий.
но, видимо, функциональность «избыточнее», чем в mercurial (улыбка). в http://www.selenic.com/mercurial/hgignore.5.html не нашёл упоминания об отрицании. поясняю:
можно игнорировать, например, все файлы, заканчивающиеся на «.c», но _не_ игнорировать файлы, заканчивающиеся, например, на «spec.c».
*.c
!*spec.c

[watashiwa_daredeska]

Так они не для этого.

А для чего?

Точнее, не очень понятно, чего ты хочешь.

Я, скорее, не хочу, чем хочу :) Я не понимаю, зачем в истории хранить принадлежность ченджсета ветке.

Локальные имена, которые вообще не будут никуда пушиться?

Не то, чтобы совсем никуда, но в общем, да.

Или ты хочешь их пушить внутри команды, но не отдавать наружу?

Внутри репозитория. Они видны снаружи, на них можно ссылаться, но они не сохраняются в истории. Как URI репозитория, из которого я тянул изменения — после того, как я вытянул изменения, теряется информация о том, откуда оно было вытянуто.

Тогда объясни своими словами, как это реализовано в git -- я попробую "перевести".

Попробую провести сразу две параллели: с объектами в памяти и ФС.

В основе репозитория git лежит некий направленный граф объектов, которые однозначно идентифицируются по id (ср. указатель)(ср. inode). Есть «точки входа» (ТВ) в этот граф, например, HEAD (ср. именованные переменные в программе)(ср. directory entry). Те объекты, до которых нельзя добраться из ТВ, двигаясь по направлению рёбер графа — мусор, он убирается сборщиком мусора (есть настраиваемое время жизни — мусор может жить некоторое время, на всякий случай). Тэги и ветки — это просто именованные ТВ в граф объектов. Когда кто-то синхронизируется с репозиторием, он может выбрать одну из ТВ и вытянуть соответствующий подграф себе, обозвав при этом так, как ему нравится (ср. передача указателя и присвоение его другой переменной)(ср. копирование файла), совершенно не важно, как называлась та ТВ, через которую он вытянул этот подграф.

Естественно, если я поддерживаю публичный репозиторий, то я поддерживаю разумные имена веток и тэгов, разумное их перемещение (например, двигать HEAD ветки «назад» в публичном репозитории противопоказано — много чего сломается у тех, кто уже синхронизировался) и т.п. Но это ограничения, накладываемые конкретно на публичный репозиторий. В своём личном я могу творить что угодно, как угодно.

[sash-kan]

2. расшифруй, пожалуйста, что означает «хранение тэгов и игноров в верифицируемых файлах»?

Не "верифицируемых". "Версифицируемых".

версифицирование тэгов.
что же, нашлась на данный момент первая фича, которая есть в mercurial, и которой нет в git-е.

p.s. вопрос нужности предлагаю не обсуждать. скорее всего, сказывается совершенно разная архитектура этих vcs.

[sash-kan]

Some Mercurial users do not use branch names at all. And there is indeed no need to assign branch names in Mercurial. Some users find them helpful, some not. Establish and apply your local consensus.

насколько понял на данный момент архитектуру mercurial:
аналогом git-веток с точки зрения пользователя можно считать hg-шные named-ветки.
аналогом git-веток с точки зрения реализации можно считать hg-шные nonamed-ветки.

[t.t]

Так они не для этого.

А для чего?

Один из типичных примеров я где-то здесь уже упоминал. Коммерческий проект, три постоянные ветки: release, testing, devel. Причём в первой -- набор постоянных же тегов, указывающих на конкретные номера релизов.

Точнее, не очень понятно, чего ты хочешь.

Я, скорее, не хочу, чем хочу Я не понимаю, зачем в истории хранить принадлежность ченджсета ветке.

Один типичный пример я привёл выше. Второй: у меня в каталоге с текстами моих статей есть небольшая кучка подкаталогов с некими "временными" вариантами текста, которые однако могли пригодиться и в будущем. Сейчас я бы вместо этой кучки подкаталогов (со временем начавших ветвиться внутри себя по сходным с их появлением причинам) использовал две-три именованных ветки по пять-десять ревизий в каждой. Это навскидку, но общей смысл, думаю, понятен.

Локальные имена, которые вообще не будут никуда пушиться?

Не то, чтобы совсем никуда, но в общем, да.

Или ты хочешь их пушить внутри команды, но не отдавать наружу?

Внутри репозитория. Они видны снаружи, на них можно ссылаться, но они не сохраняются в истории.

Букмарки или локальные теги.

Как URI репозитория, из которого я тянул изменения — после того, как я вытянул изменения, теряется информация о том, откуда оно было вытянуто.

Строго говроя, когда ты делаешь hg clone, этот URI как раз сохраняется в .hg/hgrc -- и после этого можно делать push/pull без параметров.

Тогда объясни своими словами, как это реализовано в git -- я попробую "перевести".

Попробую провести сразу две параллели: с объектами в памяти и ФС.

В основе репозитория git лежит некий направленный граф объектов, которые однозначно идентифицируются по id (ср. указатель)(ср. inode). Есть «точки входа» (ТВ) в этот граф, например, HEAD (ср. именованные переменные в программе)(ср. directory entry). Те объекты, до которых нельзя добраться из ТВ, двигаясь по направлению рёбер графа — мусор, он убирается сборщиком мусора (есть настраиваемое время жизни — мусор может жить некоторое время, на всякий случай). Тэги и ветки — это просто именованные ТВ в граф объектов. Когда кто-то синхронизируется с репозиторием, он может выбрать одну из ТВ и вытянуть соответствующий подграф себе, обозвав при этом так, как ему нравится (ср. передача указателя и присвоение его другой переменной)(ср. копирование файла), совершенно не важно, как называлась та ТВ, через которую он вытянул этот подграф.

Естественно, если я поддерживаю публичный репозиторий, то я поддерживаю разумные имена веток и тэгов, разумное их перемещение (например, двигать HEAD ветки «назад» в публичном репозитории противопоказано — много чего сломается у тех, кто уже синхронизировался) и т.п. Но это ограничения, накладываемые конкретно на публичный репозиторий. В своём личном я могу творить что угодно, как угодно.

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

[t.t]

Some Mercurial users do not use branch names at all. And there is indeed no need to assign branch names in Mercurial. Some users find them helpful, some not. Establish and apply your local consensus.

насколько понял на данный момент архитектуру mercurial:
аналогом git-веток с точки зрения пользователя можно считать hg-шные named-ветки.
аналогом git-веток с точки зрения реализации можно считать hg-шные nonamed-ветки.

И да, и нет. Что-то похожее есть (с обеих сторон); но, учитывая общую разницу подходов, различий больше, чем общностей.

[sash-kan]

Some Mercurial users do not use branch names at all. And there is indeed no need to assign branch names in Mercurial. Some users find them helpful, some not. Establish and apply your local consensus.

насколько понял на данный момент архитектуру mercurial:
аналогом git-веток с точки зрения пользователя можно считать hg-шные named-ветки.
аналогом git-веток с точки зрения реализации можно считать hg-шные nonamed-ветки.

решил отвечать на посты последовательно, но отступлю один разок, чтобы дополнить обратной картиной.

продолжая излагать на данный момент понятое в архитектуре hg:
аналогом hg-named-веток с точки зрения реализации выходит git clone.
аналогом hg-nonamed-веток с точки зрения пользователя являются удалённые git-овские ветки (нюанс: без head-а они будут жить до первого git gc (garbage collection)). целесообразность работы в git-е с удалёнными объектами, естественно, стоит под большим вопросом. а вообще, насколько вижу, аналогия достаточно точная.

[t.t]

аналогом hg-named-веток с точки зрения реализации выходит git clone.

Не совсем понял. Именованная ветка (named branch) ведь не создаёт физических копий существубщих ревизий.

аналогом hg-nonamed-веток с точки зрения пользователя являются удалённые git-овские ветки (нюанс: без head-а они будут жить до первого git gc (garbage collection)). целесообразность работы в git-е с удалёнными объектами, естественно, стоит под большим вопросом. а вообще, насколько вижу, аналогия достаточно точная.

Не совсем. Если смотреть с точки зрения пользователя, то самая основная разница в том, что безымянные ветки это реальный рабочий инструмент, который используется не в исключительных случаях, а повседневно; даже чаще, чем именованные. Кстати, описанная во многих местах схема ветвления клонами -- это ведь тоже на самом деле один из вариантов создания безымянных веток посредством clone-pull-merge. Но мне больше нравится вариант с up -r -N, чем clone-pull.

[sash-kan]

настало время тестов.

потихоньку веду тесты. наибольшая сложность — реализовать аналогичность результата. совпадение названий команд совсем не означает совпадения результатов их деятельности.

[t.t]

совпадение названий команд совсем не означает совпадения результатов их деятельности.

Это да. Самый частовстречающийся в описаниях пример -- fetch/pull.

[t.t]

Касательно контекстности. Сегодня как раз расписывал инструкцию для разработчиков для первого этапа внедрения mercurial (первый этап -- это когда у многих вообще никакого опыта с dvcs нет). Цель -- максимальное упрощение. Удалось добиться схемы взаимодействия, приводящей к "почти линейной" схеме разработки. Почти линейность -- это когда ветки возникают только при заранее несогласованных параллельных пушах; и мержатся на первой же ревизии, причём гарантировано без конфликтов.

Любопытно: для git возможна такая схема?

[t.t]

Почти линейность -- это когда ветки возникают только при заранее несогласованных параллельных пушах

Забыл уточнить, т.к. думал, что это понятно из контекста: безымянные ветки.

[watashiwa_daredeska]

Один из типичных примеров я где-то здесь уже упоминал. Коммерческий проект, три постоянные ветки: release, testing, devel. Причём в первой -- набор постоянных же тегов, указывающих на конкретные номера релизов.

Теги на релизы я понимаю. Зачем именно эти имена веток где-то окромя одного «центрального» репозитория? Разработчик в данный момент начал работать над конкретной задачей, сделал клон с нужного места истории нужной ветки и обозвал в своём репозитории эту ветку «задача-такая-то», по завершении, смержил. Постоянными и клонируемыми-то зачем эти имена веток делать?

Сейчас я бы вместо этой кучки подкаталогов (со временем начавших ветвиться внутри себя по сходным с их появлением причинам) использовал две-три именованных ветки по пять-десять ревизий в каждой. Это навскидку, но общей смысл, думаю, понятен.

Какой недостаток в этом случае у git'овых веток?

Это навскидку, но общей смысл, думаю, понятен.

В том-то и дело, что нет. Я не могу понять преимуществ hg'шного подхода к веткам и прочим тэгам и букмаркам по сравнению с git'овым.

[t.t]

Это навскидку, но общей смысл, думаю, понятен.

В том-то и дело, что нет. Я не могу понять преимуществ hg'шного подхода к веткам и прочим тэгам и букмаркам по сравнению с git'овым.

Боюсь, это уже из той самой плоскости личных предпочтений. Точно так же, как я не могу понять полезности некоторых (честно говоря, многих) уникальных свойств гита или вима, сколько мне их ни объясняли.

[kamre]

Один из типичных примеров я где-то здесь уже упоминал. Коммерческий проект, три постоянные ветки: release, testing, devel. Причём в первой -- набор постоянных же тегов, указывающих на конкретные номера релизов.

Теги на релизы я понимаю. Зачем именно эти имена веток где-то окромя одного «центрального» репозитория?

А зачем "центральный" репозиторий? Вроде в dvcs все репозитории должны быть равны. Поэтому информацию о специальных именованных ветках (вроде упомянутых выше release, testing, devel и еще специальных customer branches) удобнее иметь в каждом клоне репозитория.

Разработчик в данный момент начал работать над конкретной задачей, сделал клон с нужного места истории нужной ветки и обозвал в своём репозитории эту ветку «задача-такая-то», по завершении, смержил. Постоянными и клонируемыми-то зачем эти имена веток делать?

А в чем отличие от: разработчик сделал клон репозитория, переключился на нужную именованную ветку, поставил локальный bookmark «задача-такая-то», по завершении, смержил? Постоянные и клонируемые имена есть только у специальных веток, а не под очередную задачу. Можно все эти специальные ветки хранить в разных клонах репозитория (как часто и рекомендуется в hgbook), но иногда удобнее все иметь в одном репозитории и здесь именованные ветки как раз кстати.

[watashiwa_daredeska]

А зачем "центральный" репозиторий? Вроде в dvcs все репозитории должны быть равны.

Они равны технически, но не логически. «Центральный» — читай «референсный», «публичный, из которого публика качает релиз» и т.п.

А в чем отличие от: разработчик сделал клон репозитория

Отличие первое: в git не обязательно клонировать репозиторий, можно вытянуть одну ветку. Отличие второе, когда я вытягиваю ветку, её имя не маячит в моём репозитории, не создаёт конфликтов и вообще нафиг мне не нужно. Условно говоря, у меня может быть форк, параллельная версия продукта, в которой другие соглашения об именах веток, другой релиз-цикл и т.п. Зачем мне замусоривать репозиторий именами из исходного?

но иногда удобнее все иметь в одном репозитории и здесь именованные ветки как раз кстати.

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

[kamre]

Они равны технически, но не логически. «Центральный» — читай «референсный», «публичный, из которого публика качает релиз» и т.п.

Если при клонировании пропадают имена у веток, то они уже не равны технически. Правда необходимость в таких ветках как раз и обсуждаем.

А в чем отличие от: разработчик сделал клон репозитория

Отличие первое: в git не обязательно клонировать репозиторий, можно вытянуть одну ветку.

Насколько я знаю, в mercurial такое пока не возможно, т.е. вытащить из репозитория только одну ветку нельзя. Только обсуждения идут: http://mercurial.selenic.com/wiki/ShallowClone

Отличие второе, когда я вытягиваю ветку, её имя не маячит в моём репозитории, не создаёт конфликтов и вообще нафиг мне не нужно. Условно говоря, у меня может быть форк, параллельная версия продукта, в которой другие соглашения об именах веток, другой релиз-цикл и т.п. Зачем мне замусоривать репозиторий именами из исходного?

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

Для open source проектов такая гибкость с git ветками, конечно, удобнее. Т.е. можно иметь общий код в разных проектах, при этом никак не связывать внутренние ветки и релизы. А для закрытых коммерческих разработок такая гибкость для fork не очень нужна, проще иметь один репозиторий с именованными ветками как в cvs/svn.

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

Внутри одной именованной ветки идет также нелинейная история, так что голов может быть много. Фактически это как несколько репозиториев внтури одного получается. Для такого применения логично выглядит, когда все changesets из именованной ветки имеют признак.

[watashiwa_daredeska]

Если при клонировании пропадают имена у веток, то они уже не равны технически.

Это почему же? Содержимое ведь равно? Если скомпилять получим то же самое? Аналогично, если я скопировал файл с одной машины на другую под другим именем, он стал другим, не равным исходному?

А для закрытых коммерческих разработок такая гибкость для fork не очень нужна, проще иметь один репозиторий с именованными ветками как в cvs/svn.

Нужна. Не проще. У нас, правда, используется cvcs perforce, в едином репозитории лежат все проекты, потому что они взаимосвязаны. Если представить, как это могло бы быть реализовано на dvcs, то вытягивание проектов по зависимостям со всеми их ветками — ужас кошмарный. Если их имена веток ещё у меня под ногами путаться будут, то вообще дурдом получится. Разработчикам всегда нужна лишь одна — девелоперская ветка. Релизные ветки создаёт команда соответствующего проекта, в основном для себя, чтобы отслеживать, что в production крутится, остальным разработчикам эти релизные ветки — до лампочки.

Внутри одной именованной ветки идет также нелинейная история, так что голов может быть много.

Ну, нелинейную историю я понимаю. В git история ветки тоже может быть весьма нелинейна. Но несколько голов!? А как, простите, тогда понять, какая из голов та, которая нужна?

[kamre]

Если при клонировании пропадают имена у веток, то они уже не равны технически.

Это почему же? ...

А чтобы после клонирования поднять такой же публичный репозиторий с теми же именованными ветками что-то еще помимо клона нужно делать?

такая гибкость для fork не очень нужна, проще иметь один репозиторий с именованными ветками как в cvs/svn.

Нужна. Не проще. ...

При таком подходе именованные ветки не нужны, следует держать отдельные клоны репозитория, как это и рекомендуется в hgbook.

Внутри одной именованной ветки идет также нелинейная история, так что голов может быть много.

Ну, нелинейную историю я понимаю. В git история ветки тоже может быть весьма нелинейна. Но несколько голов!? А как, простите, тогда понять, какая из голов та, которая нужна?

Если история нелинейная, то очевидно что в какой-то момент было две головы )

[sash-kan]

продолжаю последовательно отвечать:

Intelligent Merging after Moves or Renames
Git: No. As detailed in the Git FAQ: "Git has a rename command git mv, but that is just a convenience. The effect is indistinguishable from removing the file and adding another with different name and the same content."
Mercurial: Yes, intelligent merging after renames is supported. the Mercurial book says: "If I modify a file, and you rename it to a new name, and then we merge our respective changes, my modifications to the file under its original name will be propagated into the file under its new name. (This is something you might expect to 'simply work,' but not all revision control systems actually do this.)"

прекрасно работает.

Код: Выделить всё

в первом клоне:
clone1$ git mv file1 file2 # переименовываем
clone1$ git commit         # коммитим
clone1$ git push           # коммитим в общий репозиторий
затем во втором:
clone2$ edit file1         # вносим изменения
clone2$ git commit -a      # коммитим
clone2$ git pull           # получаем обновления из общего репозитория
clone2$ less file2         # видим, что файл переименовался, и все наши изменения — на месте

File and Directory Copies
Git: No. Copies are not supported.
Mercurial: Yes. Copies are supported

уже написали, что с этим прекрасно справляется команда cp.

Ability to Work only on One Directory of the Repository
Git: No. However, commits could be restricted somewhat, see the "Repository Permissions".
Mercurial: It is possible to commit changes only in a subset of the tree. There are plans for partial checkouts.

что-то непонятное. ограничение на коммит только в определённые каталоги? hook-и для этого есть.
если про возможность «разбиения» правок, так это уже обсудили выше — в git-е это есть изначально и «богато» реализовано.
если про возможность «разбиения» коммитов при мёрдже, так это тоже возможно: http://stackoverflow.com/questions/449541/...-with-git-merge
p.s. вообще, я, в принципе, понимаю, чем продиктовано это конкретное сравнение и, главное, в чём его некорректность:
в том самом кардинальном отличии git-а от всех прочих вместе взятых [d]vcs. git не файл-, а commit-ориентирован. в репозитории (.git/) нет истории отдельных файлов/каталогов. есть по-commit-ная история diff-ов.

Documentation
Git: Medium. The short help is too terse and obscure. The man pages are extensive, but tend to be confusing. The are many tutorials.
Mercurial: Very good. There is a companion book and a wiki. Every command has integrated help.

субъективно.
вообще документации по git-у — навалом. найдётся и разной степени детализации и в расчёте на разную степень подготовленности.
и на русском есть прекрасный перевод общей документации, выполненный Русланом Хихиным. ссылка есть в озвученных выше моих букмарксах. повторю: http://www.freesource.info/wiki/RuslanHihin/gitusermanual

Command Set
Git: Command set is very feature-rich, and not compatible with CVS.
Mercurial: Tries to follow CVS conventions, but deviates where there is a different design.

можно эмулировать команды с помощью git-овского механизма alias-ов. пример (секция useful aliases) https://wincent.com/wiki/Git_quickstart
можно хоть целый набор команд в один alias завернуть.
и документации для мигрантов с cvs предостаточно: http://www.google.ru/search?q=git+for+cvs+users , в частности:
http://git.or.cz/course/cvs.html
http://www.kernel.org/pub/software/scm/git...-migration.html
http://www.chem.helsinki.fi/~jonas/git_guides/HTML/CVS2git/

[watashiwa_daredeska]

А чтобы после клонирования поднять такой же публичный репозиторий с теми же именованными ветками что-то еще помимо клона нужно делать?

Что-то не до конца понял вопрос.
По-умолчанию, git clone клонирует целиком, с ветками, тэгами и т.п. Чтобы вытащить отдельную ветку надо пользоваться другими инструментами, например, git pull.

При таком подходе именованные ветки не нужны, следует держать отдельные клоны репозитория, как это и рекомендуется в hgbook.

Круг -дцатый. Я уже привёл use case'ы, когда ветки hg неудобны по сравнению с git. Можете привести use case, когда ветки hg имеют явное преимущество? Например, зачем может понадобиться знать, какой ветке принадлежит(ал) какой-то там ченджсет в истории? Кстати, а какой ветке он принадлежит, если до него можно дойти из головы development, release-1.0 и release-2.0?

Если история нелинейная, то очевидно что в какой-то момент было две головы )

У ветки никогда не было двух голов. В какой-то момент было две ветки, разных, с разными именами, потом они слились. Но голова у каждой ветки в каждый момент одна.

Скажем, у ветки devel была линейная история, от неё отфоркали ветку feature-foo, стало две ветки с линейной историей, у каждой своя голова (одна). Когда feature-foo вмержили в devel, у ветки devel стала нелинейная история, но осталась одна голова, у ветки feature-foo история осталась линейная. Если ветка feature-foo ещё нужна, то текущее состояние devel вмерживается в feature-foo (теперь devel и feature-foo будут показывать на один и тот же коммит), и у feature-foo также появляется нелинейная история.

[t.t]

Intelligent Merging after Moves or Renames
Git: No. As detailed in the Git FAQ: "Git has a rename command git mv, but that is just a convenience. The effect is indistinguishable from removing the file and adding another with different name and the same content."
Mercurial: Yes, intelligent merging after renames is supported. the Mercurial book says: "If I modify a file, and you rename it to a new name, and then we merge our respective changes, my modifications to the file under its original name will be propagated into the file under its new name. (This is something you might expect to 'simply work,' but not all revision control systems actually do this.)"

прекрасно работает.

Код: Выделить всё

в первом клоне:
clone1$ git mv file1 file2 # переименовываем
clone1$ git commit         # коммитим
clone1$ git push           # коммитим в общий репозиторий
затем во втором:
clone2$ edit file1         # вносим изменения
clone2$ git commit -a      # коммитим
clone2$ git pull           # получаем обновления из общего репозитория
clone2$ less file2         # видим, что файл переименовался, и все наши изменения — на месте

Ты не так понял. Конечно, то, что ты написал, работать должно -- куда же без этого? Там о другом речь: покажи мне историю обоих файлов после этих действий.

File and Directory Copies
Git: No. Copies are not supported.
Mercurial: Yes. Copies are supported

уже написали, что с этим прекрасно справляется команда cp.

Опять же. Вносим правки; копируем этой командой; вносим следующие правки: в копию одни, в оригинал -- другие; коммитим (да, хочется, чтобы это всё было одним коммитом). Как будет после этого выглядеть история копии и оригинала?