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

[watashiwa_daredeska]

Функционал dpkg пишется на shell слёту. Тем не менее, написан dpkg всё-таки на си (сейчас; изначально был на перле). Но ты ведь не будешь спорить, что dpkg -- это unix-way?

Не буду. Конструктор ведь остался? Если убрать конструктор, из которого изначально был собран dpkg, то вся конструкция в целом уже не будет unix-way. Также и с git — да, когда-то высокоуровневые команды были на shell, теперь их переписали на C, но низкоуровневый конструктор по прежнему доступен.

[sash-kan]

1. скорость: разница столь мала и неповсеместна, столь зависима от контекста измерений, что преимуществом она может являться лишь в очень малом проценте случаев;

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

2. простота архитектуры: так и не увидел ни единого весомого аргумента, что архитектура git принципиально проще архитектуры mercurial, хотя просил об этом раз шесть как минимум;

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

3. функциональность: устал повторять, что во многих случаях функциональность git _избыточна_, т.е. является не преимуществом, а недостатком;

кому-то нужна дополнительная функциональность, кому-то не нужна. тот, кто считает свои нужды единственно верными — увы, не прав.

4. простота расширения: далеко не всегда расширение нужно как таковое, и уж тем более далеко не всегда важна его простота;

да, я тоже думаю, что эмуляция incoming/outgoing в виде одной команды — совершенно ненужная вещь. несмотря на простоту реализации.

а) простота (лёгкость) изучения;

субъективно.

б) простота (стройность) устройства: например (то, о чём уже говорили), наличие одновременно index-а, полок и веток, мною воспринимается как _каша_;

субъективно.

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

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

Да и сам тот факт, что меня тебе не удаётся переубедить, даже после подключения к теме других наших коллег, выбравших git, разве не свидетельствует о субъективности само по себе? (:

у тебя давно сложилось предвзятое мнение, которое ты распространяешь и на меня:

Мне как раз непонятна позиция многих поклонников git, вида "существуют два вида vcs: git и неправильные" (ты и сам базар свалил в одну кучу с svn, а о hg вообще забыл, хотя я речь веду именно о нём). Базируется она (прямо, либо косвенно -- путём принятия или трансляции мнений других git-последователей) почти полностью на безапелляционных (по форме) заявлениях Линуса. Но его позиция _весьма_ субъективна и заангажирована (по сути). Начнём с того, что моделей использования dvcs может быть очень много, и модель, продвигаемая Линусом (снова-таки, как "единственно верная") не только не наиболее распространена, но и вообще имеет множество спорных моментов. А во многих из других моделей преимущества git (и так достаточно эфемерные) полностью нивелируются, зато недостатки (которые Линус вообще предпочитает замалчивать, либо недостатками не считать по определению -- по крайней мере, на публику) становятся более существенными.

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

[t.t]

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

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

Ты мне вот что лучше скажи. Есть два продукта. У одного есть набор фич А; у второго -- набор фич Б. По твоим же словам, кто-то предпочтёт набор фич А, что-то -- набор фич Б (с этим я полностью согласен). Внимание, вопрос: какой из наборов фич -- А или Б -- считать объективным (т.к. от субъективности ты отказываешься) преимуществом, и главное почему?

[t.t]

Функционал dpkg пишется на shell слёту. Тем не менее, написан dpkg всё-таки на си (сейчас; изначально был на перле). Но ты ведь не будешь спорить, что dpkg -- это unix-way?

Не буду. Конструктор ведь остался? Если убрать конструктор, из которого изначально был собран dpkg, то вся конструкция в целом уже не будет unix-way. Также и с git — да, когда-то высокоуровневые команды были на shell, теперь их переписали на C, но низкоуровневый конструктор по прежнему доступен.

Идём дальше. (: Получается, разница между git и mercurial в этом смысле лишь в том, что первый когда-то был реализован на shell, а второй -- не был. Так?

[/dev/random]

Идём дальше. (: Получается, разница между git и mercurial в этом смысле лишь в том, что первый когда-то был реализован на shell, а второй -- не был. Так?

Вопрос не мне адресовался, но вставлю своё мнение: не в этом, а в том, что для git практически любое расширение можно реализовать в виде простенького скрипта на shell/perl/подставить_язык.

[watashiwa_daredeska]

Получается, разница между git и mercurial в этом смысле лишь в том, что первый когда-то был реализован на shell, а второй -- не был. Так?

Нет. Разница в том, что конструктор, на котором был реализован и может быть реализован снова git, остался, а конструктора, на котором можно реализовать mercurial нету, есть лишь готовое решение.

[sash-kan]

Ты мне вот что лучше скажи. Есть два продукта. У одного есть набор фич А; у второго -- набор фич Б. По твоим же словам, кто-то предпочтёт набор фич А, что-то -- набор фич Б (с этим я полностью согласен). Внимание, вопрос: какой из наборов фич -- А или Б -- считать объективным (т.к. от субъективности ты отказываешься) преимуществом, и главное почему?

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

[t.t]

1. скорость: разница столь мала и неповсеместна, столь зависима от контекста измерений, что преимуществом она может являться лишь в очень малом проценте случаев;

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

Моё высказывание базируется на результатах тестов, на которые ты сам приводил ссылки.

2. простота архитектуры: так и не увидел ни единого весомого аргумента, что архитектура git принципиально проще архитектуры mercurial, хотя просил об этом раз шесть как минимум;

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

Т.е. (по крайней мере пока) этот пункт отбрасываем.

кому-то нужна дополнительная функциональность, кому-то не нужна. тот, кто считает свои нужды единственно верными — увы, не прав.

А теперь внимание, вопрос: кто из нас считает свои нужды единственно верными? Кто из нас не хочет соглашаться, что выбор субъективен? (:

да, я тоже думаю, что эмуляция incoming/outgoing в виде одной команды — совершенно ненужная вещь. несмотря на простоту реализации.

Ну а мне эти команды удобны; а "эксклюзивный" функционал git -- не нужен. Т.е. опять всё субъективно, не так ли?

а) простота (лёгкость) изучения;

субъективно.

б) простота (стройность) устройства: например (то, о чём уже говорили), наличие одновременно index-а, полок и веток, мною воспринимается как _каша_;

субъективно.

Верно. (: Что я и говорю. А ты соглашаться не хочешь.

у тебя давно сложилось предвзятое мнение, которое ты распространяешь и на меня:

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

[t.t]

Получается, разница между git и mercurial в этом смысле лишь в том, что первый когда-то был реализован на shell, а второй -- не был. Так?

Нет. Разница в том, что конструктор, на котором был реализован и может быть реализован снова git, остался, а конструктора, на котором можно реализовать mercurial нету, есть лишь готовое решение.

Почему нету? Я уверен, что функционал mercurial _можно_ реализовать на том же конструкторе. Ведь "можно реализовать" и "когда-то был реализован" -- это разные вещи.

Ты мне вот что лучше скажи. Есть два продукта. У одного есть набор фич А; у второго -- набор фич Б. По твоим же словам, кто-то предпочтёт набор фич А, что-то -- набор фич Б (с этим я полностью согласен). Внимание, вопрос: какой из наборов фич -- А или Б -- считать объективным (т.к. от субъективности ты отказываешься) преимуществом, и главное почему?

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

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

[sash-kan]

ну вот. а я так старался отвечать. хотя бы кратко.

Ты мне вот что лучше скажи. Есть два продукта. У одного есть набор фич А; у второго -- набор фич Б. По твоим же словам, кто-то предпочтёт набор фич А, что-то -- набор фич Б (с этим я полностью согласен). Внимание, вопрос: какой из наборов фич -- А или Б -- считать объективным (т.к. от субъективности ты отказываешься) преимуществом, и главное почему?

понимаешь, ты, imho, явно считаешь ограничение функциональности фичей. я же считаю это отсутствием фичи (фич).
эта разница в определении «что считать фичей» (возможно, кажущаяся) и не позволяет мне ответить напрямую на этот, казалось бы, простой вопрос.

Было интересно.

взаимно.

[watashiwa_daredeska]

Почему нету? Я уверен, что функционал mercurial _можно_ реализовать на том же конструкторе. Ведь "можно реализовать" и "когда-то был реализован" -- это разные вещи.

Понимаешь, аналог того же dpkg можно реализовать на shell и он будет работать не с какими-то абстрактными пакетами, а с теми же deb. Только что проверил, что после ar rc <имя_пакета> debian-binary control.tar.gz data.tar.gz получается обычный deb-пакет. file распознаёт его как deb-пакет, и dpkg его понимает.

Реализовать функциональный аналог mercurial на конструкторе git можно, но этот аналог будет работать на репозитории другого формата, т.е. интероперабельности не будет.

[t.t]

ну вот. а я так старался отвечать. хотя бы кратко.

Ты мне вот что лучше скажи. Есть два продукта. У одного есть набор фич А; у второго -- набор фич Б. По твоим же словам, кто-то предпочтёт набор фич А, что-то -- набор фич Б (с этим я полностью согласен). Внимание, вопрос: какой из наборов фич -- А или Б -- считать объективным (т.к. от субъективности ты отказываешься) преимуществом, и главное почему?

понимаешь, ты, imho, явно считаешь ограничение функциональности фичей. я же считаю это отсутствием фичи (фич).
эта разница в определении «что считать фичей» (возможно, кажущаяся) и не позволяет мне ответить напрямую на этот, казалось бы, простой вопрос.

Ты меня не понял. А я ведь специально написал "набор фич", а не "фича". У меркуриала один набор фич, у гита -- другой. Они сильно пересекаются, но ни один из них не входит во второй полностью. Какой сильнее выходит за пределы этого пересечения -- вопрос спорный. Точнее, как я и говорю, субъективный и контекстно-зависимый: один человек в одной ситуации будет использовать по полной фичи git и не нуждаться в фичах mercurial; другой -- ровно наоборот. Если я неправ, то укажи, пожалуйста, в каком месте.

[t.t]

Почему нету? Я уверен, что функционал mercurial _можно_ реализовать на том же конструкторе. Ведь "можно реализовать" и "когда-то был реализован" -- это разные вещи.

Понимаешь, аналог того же dpkg можно реализовать на shell и он будет работать не с какими-то абстрактными пакетами, а с теми же deb.

Правильно, можно. И аналог mercurial можно; который будет работать с теми же хранилищами.

Только что проверил, что после ar rc <имя_пакета> debian-binary control.tar.gz data.tar.gz получается обычный deb-пакет. file распознаёт его как deb-пакет, и dpkg его понимает.

Рано остановился. Растарь оба внутренних архива, поменяй что-нибудь в файлах пакета и в control и запакуй всё обратно; затем попробуй установить получившееся с помощью dpkg. С вероятностью, очень сильно превышающей 50%, ничего не получится.

Реализовать функциональный аналог mercurial на конструкторе git можно, но этот аналог будет работать на репозитории другого формата, т.е. интероперабельности не будет.

Зачем на конструктиве git? На конструктиве base-system.

[/dev/random]

Зачем на конструктиве git? На конструктиве base-system.

Вот это и есть то, что я назвал "переписать, а не логически разделить"

[t.t]

Зачем на конструктиве git? На конструктиве base-system.

Вот это и есть то, что я назвал "переписать, а не логически разделить"

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

[sash-kan]

ну вот. а я так старался отвечать. хотя бы кратко.

Ты мне вот что лучше скажи. Есть два продукта. У одного есть набор фич А; у второго -- набор фич Б. По твоим же словам, кто-то предпочтёт набор фич А, что-то -- набор фич Б (с этим я полностью согласен). Внимание, вопрос: какой из наборов фич -- А или Б -- считать объективным (т.к. от субъективности ты отказываешься) преимуществом, и главное почему?

понимаешь, ты, imho, явно считаешь ограничение функциональности фичей. я же считаю это отсутствием фичи (фич).
эта разница в определении «что считать фичей» (возможно, кажущаяся) и не позволяет мне ответить напрямую на этот, казалось бы, простой вопрос.

Ты меня не понял. А я ведь специально написал "набор фич", а не "фича". У меркуриала один набор фич, у гита -- другой. Они сильно пересекаются, но ни один из них не входит во второй полностью. Какой сильнее выходит за пределы этого пересечения -- вопрос спорный. Точнее, как я и говорю, субъективный и контекстно-зависимый: один человек в одной ситуации будет использовать по полной фичи git и не нуждаться в фичах mercurial; другой -- ровно наоборот. Если я неправ, то укажи, пожалуйста, в каком месте.

мне кажется, что ты не прав в том месте, где говоришь, что в mercurial есть фичи, которых нет в git-е.
косвенно это моё h.o. подтверждается тем, что уникальных mercurial-овских фич, насколько я помню, озвучено не было. прозвучал лишь намёк:

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

из дальнейшего вспоминается лишь incoming/outgoing. но с ними, вроде, разобрались.

[t.t]

мне кажется, что ты не прав в том месте, где говоришь, что в mercurial есть фичи, которых нет в git-е.
косвенно это моё h.o. подтверждается тем, что уникальных mercurial-овских фич, насколько я помню, озвучено не было. прозвучал лишь намёк:

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

из дальнейшего вспоминается лишь incoming/outgoing. но с ними, вроде, разобрались.

Под "фичами" я имею ввиду не только добавочный (по сравнению с другой системой) функционал, но и иную реализацию. Думаю, ты не будешь, спорить, что многое в этих двух системах реализовано по-разному.

Но касаемо конкретно фич тоже интересно было бы обсудить. Для начала, как насчёт named branches и хранения тегов и игноров (вот насчёт последнего не помню, есть ли разница) в виде весифицируемых файлов?

[watashiwa_daredeska]

Рано остановился. Растарь оба внутренних архива, поменяй что-нибудь в файлах пакета и в control и запакуй всё обратно; затем попробуй установить получившееся с помощью dpkg. С вероятностью, очень сильно превышающей 50%, ничего не получится.

Ради эксперимента я сбацал полностью пакет с нуля не пользуясь инструментарием DEB/DPKG.

user@localhost

$ mkdir -p control data/usr/share/doc/dummy-package $ cat >control/control <<EOF Package: dummy-package Version: 0.1-1 Architecture: all Maintainer: watashiwa_daredeska <watashiwa_daredeska@unixforum.org> Section: dummy Priority: extra Description: Dummy package Just check how can I make a package completely by hand. . No DEB/DPKG tools have been used! EOF $ echo 'Dummy package.' >data/usr/share/doc/dummy-package/README $ (cd data; md5sum usr/share/doc/dummy-package/README >../control/md5sums) $ (cd control; tar c . | gzip -c9 >../control.tar.gz) $ (cd data; tar c . | gzip -c9 >../data.tar.gz) $ echo 2.0 >debian-binary $ ar rc dummy-package_0.1_all.deb debian-binary control.tar.gz data.tar.gz

user@localhost

$ sudo dpkg -i dummy-package_0.1_all.deb Selecting previously deselected package dummy-package. (Reading database ... 333489 files and directories currently installed.) Unpacking dummy-package (from dummy-package_0.1_all.deb) ... Setting up dummy-package (0.1-1) ... $ cat /usr/share/doc/dummy-package/README Dummy package. $ aptitude show dummy-package Package: dummy-package New: yes State: installed Automatically installed: yes Version: 0.1-1 Priority: extra Section: dummy Maintainer: watashiwa_daredeska <watashiwa_daredeska@unixforum.org> Uncompressed Size: 0 Description: Dummy package Just check how can I make a package completely by hand. No DEB/DPKG tools have been used! $

И аналог mercurial можно; который будет работать с теми же хранилищами.

Зачем на конструктиве git? На конструктиве base-system.

user@localhost

$ cat .hg/dirstate 8qa\"g4z�� ���=�?n��kK̓�README

user@localhost

$ cat .hg/store/data/_r_e_a_d_m_e.i &%��������*ʤǰ�^�3k�|R��=juDummy project to test Mercurial SCM. &Nk���� ��w�7�b�R��{��ᾌ�x�%�1 �@D�Ԟb[�!x��.�D6�{}�_<Y�o?0� ؓ8c�j���W�œ����\'J��QjL4�n���

Нафиг-нафиг.

[drBatty]

Нафиг-нафиг.

помнится в доке говорилось, что чуть более чем всё в hg сжато bzip2, причём последний можно заменить на что угодно. Ну например на cat...

[watashiwa_daredeska]

user@localhost

$ file .hg/store/data/_r_e_a_d_m_e.i .hg/store/data/_r_e_a_d_m_e.i: raw G3 data, byte-padded $ bzip2 -dc .hg/store/data/_r_e_a_d_m_e.i bzip2: .hg/store/data/_r_e_a_d_m_e.i is not a bzip2 file.

Я не знаю, что такое G3 data, но это точно не bzip2.

UPD: гугление показало, что это, похоже, какие-то факсовые данные, что, очевидно, полная чушь.

[sash-kan]

Под "фичами" я имею ввиду не только добавочный (по сравнению с другой системой) функционал, но и иную реализацию.

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

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

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

Но касаемо конкретно фич тоже интересно было бы обсудить. Для начала, как насчёт named branches и хранения тегов и игноров (вот насчёт последнего не помню, есть ли разница) в виде весифицируемых файлов?

1. named branches
просмотрел http://mercurial.selenic.com/wiki/NamedBranches , не увидел отличий от git-а. ровно те же branch+checkout (правда, жутко урезанные в функциональности — сравни man git-branch, man git-checkout). а что, в mercurial есть безымянные ветки? здесь вроде тоже имена присутствуют.
2. расшифруй, пожалуйста, что означает «хранение тэгов и игноров в верифицируемых файлах»? и что именно под «игнорами» понимается? тэги, как я понял, они и в африке тэги (пусть и урезанные — сравни с man git-tag).

[t.t]

Под "фичами" я имею ввиду не только добавочный (по сравнению с другой системой) функционал, но и иную реализацию.

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

Я не предлагаю сравнивать. Я предлагаю согласиться в том, что:
1. разница есть;
2. эта разница влияет на тот самый "стиль работы" с системой;
3. соответственно, субъективный фактор может присутствовать -- или, другими словами, выбор между git и mercurial зависит _не только_ от набора функций.

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

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

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

Но касаемо конкретно фич тоже интересно было бы обсудить. Для начала, как насчёт named branches и хранения тегов и игноров (вот насчёт последнего не помню, есть ли разница) в виде весифицируемых файлов?

1. named branches
просмотрел http://mercurial.selenic.com/wiki/NamedBranches , не увидел отличий от git-а. ровно те же branch+checkout (правда, жутко урезанные в функциональности — сравни man git-branch, man git-checkout). а что, в mercurial есть безымянные ветки? здесь вроде тоже имена присутствуют.

Цитата из именно этй ссылки:

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.

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

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

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

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

[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.)"

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

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.

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.

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.

[t.t]

Следующее найденное мною сравнение столь нейтрально и столь познавательно, что его я не буду цитировать, а рекомендую прочитать полностью:
http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/
От себя дам только один дополнительный комментарий:

...The commit can create a new branch or extend an existing one. However, working this way can be a bit confusing unless you use tags, named branches or a GUI to see the project history graphically.

На самом деле гуй не нужен, да и имена с тегами необязательны: есть отличное расширение GraphLog, идущее в комплекте (т.е. для доступности команды hg glog достаточно добавить строку "hgext.graphlog=" в секцию [extensions] локального конфига). Описание и примеры здесь: http://mercurial.selenic.com/wiki/GraphlogExtension

[/dev/random]

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

А команда cp чем не угодила?

Ability to Work only on One Directory of the Repository
Git: No. However, commits could be restricted somewhat, see the "Repository Permissions".

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

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 ничуть не меньше, чем по hg, а маны в git'е гораздо качественнее.

[t.t]

Подробное пояснение различной реализации веток в git и mercurial:
http://mercurial.selenic.com/wiki/BranchingExplained

[t.t]

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

А команда cp чем не угодила?

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

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 ничуть не меньше, чем по hg, а маны в git'е гораздо качественнее.

Опять-таки, субъективно. Мне нравится схема документации меркуриала: для начала читаешь hg help; если мало, читаешь ман (редко на самом деле); если нужно получить понимание каких-то вещей, идёшь в вики или hgbook.

С гитом ситуация другая: help не даёт нормальной информации; маны достаточно тяжеловесны; если что-то непонятно из манов -- общее решение: just google it.

Особенно неприятен последний пункт. Дело даже не в том, что я люблю централизованную информацию (т.е. опять-таки субъективно). Распределённость -- это в том числе возможность работать без сети. Оффлайновой копии hgbook мне будет достаточно в подавляющем большинстве случаев. В большинстве оставшихся поможет оффлайновая копия вики.

[/dev/random]

читаешь ман (редко на самом деле)

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

[t.t]

Продолжаю постить ссылки. Одно из первоначально прочитанных мною сравнений: http://code.google.com/p/support/wiki/DVCSAnalysis

читаешь ман (редко на самом деле)

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

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

[/dev/random]

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

Ладно, ладно. Просто пошутил.