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

[drBatty]

/dev/random
Portnov
спасибо. понял.

[t.t]

делюсь накопленными интересными и не очень ссылками «про git».
https://www.google.com/bookmarks/l#!thr...c8W3woQlIHt6vwk
первой ссылкой идёт «басня о git». буквально «на пальцах» объясняется, как последовательно складывалась архитектура git-хранилища.

Спасибо. В elinks-е страница нормально не отобразилась, а midori через gprs -- это что-то страшное. Доберусь до большой машины -- посмотрю.

Недостаток в отсутствии этой фичи у других dvcs. Впрочем, как уже заметил sash-kan, _этот_ недостаток не является существенным. Т.е. пример неудачный. Но остальных я не запомнил...

а... это клонирование репа с первого сервера на второй(сервер), при том что тот кто клонирует вообще это делает с мобильного телефона? круто. Ну значит я ртуть изучаю. Спасибо, убедили.

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

Вообще, самые простые команды в git и hg полностью совпадают.

А он умеет, скажем, git add и git commit без параметров? Когда выбирал, не посмотрел, а на практике оказалось очень удобно.

[drBatty]

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

а что-то, как я понял, git он для ядра заточен, да и название непонятное (что такое Hg я знаю...). Пока ковыряю ртуть, вроде не так уж и сложно... И документации достаточно (есть даже и по-русски!)

[t.t]

Да, выбор действительно больше субъективен. (: Я у кого-то даже читал, что он остановился на hg, т.к. на одну букву короче -- набирать быстрее. (:

[drBatty]

Да, выбор действительно больше субъективен. (: Я у кого-то даже читал, что он остановился на hg, т.к. на одну букву короче -- набирать быстрее. (:

намного быстрее - кнопки ещё и расположены рядом. (:

[sash-kan]

А он умеет, скажем, git add и git commit без параметров? Когда выбирал, не посмотрел, а на практике оказалось очень удобно.

к git add по умолчанию надо хотя бы точку добавить.
git commit без параметров по умолчанию откроет редактор, прописанный в первом из встреченных: $GIT_EDITOR, core.editor configuration variable, $VISUAL, $EDITOR.

p.s. всё это помимо того, что можно назначить git алиас для любой команды (это не shell alias!). ссылку я приводил выше.

намного быстрее - кнопки ещё и расположены рядом. (:

alias g=git? (улыбка)

[sash-kan]

В elinks-е страница нормально не отобразилась

букмарки, наверно не отобразились? потому что «басня» должна работать нормально: http://hades.name/blog/2009/05/23/the-git-parable-ru/

[t.t]

А он умеет, скажем, git add и git commit без параметров? Когда выбирал, не посмотрел, а на практике оказалось очень удобно.

к git add по умолчанию надо хотя бы точку добавить.

Ну, точку можно и добваить, она не длинная. (:

git commit без параметров по умолчанию откроет редактор, прописанный в первом из встреченных: $GIT_EDITOR, core.editor configuration variable, $VISUAL, $EDITOR.

Это ты про задание описания коммита? Нет, я о другом: список файлов или каталогов перечислять не нужно. Впрочем, наверное тоже достаточно точки.

p.s. всё это помимо того, что можно назначить git алиас для любой команды (это не shell alias!). ссылку я приводил выше.

Насколько я помню, hg тоже умеет.

намного быстрее - кнопки ещё и расположены рядом. (:

alias g=git? (улыбка)

Это я больше для юмора и написал. (:

В elinks-е страница нормально не отобразилась

букмарки, наверно не отобразились? потому что «басня» должна работать нормально: http://hades.name/blog/2009/05/23/the-git-parable-ru/

Да, именно букмарки. Спасибо за ссылку, почитаю надосуге.

[sash-kan]

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

не надо никаких точек commit-у. без параметров откроется редактор для комментария к коммиту.
а коммититься будут все изменения, что внесены в index с помощью git add. важно: не всё, что изменилось, а только то, что в index-е.
index — насколько я знаю, исключительно git-овская фича. у Oliver Steele в блоге хорошо (в частности) про index написано. доступно. правда, по английски. в приведённых выше букмарках ссылка есть. повторю отдельно: http://osteele.com/archives/2008/05/my-git-workflow
обычно, впрочем, поступают по-простому, как и в традиционных vcs-ах:
$ git commit -a
т.е., git сам найдёт все изменённые файлы, включит их в index, и на их основе будет делать commit.

[t.t]

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

не надо никаких точек commit-у. без параметров откроется редактор для комментария к коммиту.
а коммититься будут все изменения, что внесены в index с помощью git add. важно: не всё, что изменилось, а только то, что в index-е.
index — насколько я знаю, исключительно git-овская фича. у Oliver Steele в блоге хорошо (в частности) про index написано. доступно. правда, по английски. в приведённых выше букмарках ссылка есть. повторю отдельно: http://osteele.com/archives/2008/05/my-git-workflow
обычно, впрочем, поступают по-простому, как и в традиционных vcs-ах:
$ git commit -a
т.е., git сам найдёт все изменённые файлы, включит их в index, и на их основе будет делать commit.

Да, извини, туплю. Конечно, по умолчанию будут коммититься те файлы, что были добавлены. Т.е. с коммитом всё совершенно аналогично.

И ещё раз спасибо за ссылку, отличная басня. Но принципиальных различий в архитектуре так и не увидел.

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

[drBatty]

p.s. всё это помимо того, что можно назначить git алиас для любой команды (это не shell alias!). ссылку я приводил выше.

Насколько я помню, hg тоже умеет.

там команды-то... зачем для ci алиас?

а коммититься будут все изменения, что внесены в index с помощью git add. важно: не всё, что изменилось, а только то, что в index-е.

я только начинаю разбираться, но вроде в hg, то что не внесено в "индекс" (не добавлено hg add), то просто отображается с вопросами, типа
new_file1 ?
new_file2 ?
и т.д. Причём как я понял, изменения в этих левых файлах не отслеживаются. Или я не прав?

[Portnov]

При любом "переписывании истории" в гите правятся только ссылки. Это как операции вставки-удаления-замены над связными списками (элемент списка - коммит). Сами данные из гитовского репозитория удаляются, афаик, только при git gc (явная команда для выкидывания коммитов и других объектов, на которые никто не ссылается).

[drBatty]

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

Спасибо. Ваш пост говорит, что я вроде-бы всё правильно понял...
А удаление снимков - ИМХО плохая идея. Тут я согласен.

[t.t]

p.s. всё это помимо того, что можно назначить git алиас для любой команды (это не shell alias!). ссылку я приводил выше.

Насколько я помню, hg тоже умеет.

там команды-то... зачем для ci алиас?

Ну, ci ведь не единственная команда, есть и подлиннее. (;

а коммититься будут все изменения, что внесены в index с помощью git add. важно: не всё, что изменилось, а только то, что в index-е.

я только начинаю разбираться, но вроде в hg, то что не внесено в "индекс" (не добавлено hg add), то просто отображается с вопросами, типа
new_file1 ?
new_file2 ?
и т.д. Причём как я понял, изменения в этих левых файлах не отслеживаются. Или я не прав?

Правы.

При любом "переписывании истории" в гите правятся только ссылки. Это как операции вставки-удаления-замены над связными списками (элемент списка - коммит). Сами данные из гитовского репозитория удаляются, афаик, только при git gc (явная команда для выкидывания коммитов и других объектов, на которые никто не ссылается).

Да, в hg этого нельзя сделать даже "явной командой". На мой взгляд, история должна быть полной -- что бы там кто ни придумал; иначе ситуации "шеф, всё пропало!" © не исключены.

[sash-kan]

вроде в hg, то что не внесено в "индекс" (не добавлено hg add)

даже если в mercurial есть сущность под названием index, не стоит её путать с git-овым index-ом.
но я подозреваю, что сущности такой нет. следовательно, лучше оставить git-ово git-у.

[drBatty]

даже если в mercurial есть сущность под названием index, не стоит её путать с git-овым index-ом.
но я подозреваю, что сущности такой нет. следовательно, лучше оставить git-ово git-у.

вот с этим ещё не разобрался, но есть что-то, что запоминает все файлы вместе с их sha1. И новые файлы не добавляются сами по себе. Как я понимаю - это индекс.

[t.t]

вроде в hg, то что не внесено в "индекс" (не добавлено hg add)

даже если в mercurial есть сущность под названием index, не стоит её путать с git-овым index-ом.
но я подозреваю, что сущности такой нет. следовательно, лучше оставить git-ово git-у.

Есть сущность, в точности равная git-овому index-у, но index-ом она (насколько я знаю) не называется.

[sash-kan]

Есть сущность, в точности равная git-овому index-у, но index-ом она (насколько я знаю) не называется.

можно продемонстрировать в виде команд и их вывода?

[/dev/random]

Есть сущность, в точности равная git-овому index-у, но index-ом она (насколько я знаю) не называется.

Её нет. Максимально близкая сущность называется dirstate, но она, в отличие от index'а, не включает в себя содержимое файлов, а только краткую информацию о них. В git команда commit запишет в репозиторий именно содержимое index'а, и даже если какие-то файлы после этого изменились, записаны будут их старые версии. В hg такого временного хранилища нет, и записаны файлы будут в том виде, в котором они сейчас находятся в дереве.

[t.t]

Прошу прощения, я, возможно, не совсем верно понял.

а коммититься будут все изменения, что внесены в index с помощью git add. важно: не всё, что изменилось, а только то, что в index-е.

Вот здесь имелось ввиду, что в index с помощью add добавляются именно изменения, или файлы? Т.е., если сделать

Shell

git init echo 1 >file git add file echo 2 >>file git commit

то изменение 2 будет закоммичено или нет?

[sash-kan]

изменения, или файлы?

файлов, грубо говоря, в git-е нет. есть diff-ы.

то изменение 2 будет закоммичено или нет?

нет.


t.t
загляни всё-таки в блог, ссылку на который я приводил: http://osteele.com/archives/2008/05/my-git-workflow
основная идея index-а видна и в первой картинке. но и текст почитать стоит. там (в том числе и) о разных моделях использования репозитория идёт речь.

[t.t]

Да, уже вспомнил, извини. Это была одна из неосновных причин выбрать mercurial. (: Идея принудительно добавлять каждое изменение (а не файл) показалась мне несколько странной. Да, файлов внутри dvcs (любой, не только git) нет, но они есть в самих хранимых данных, и потому часто удобнее оперировать именно файлами, а не диффами. Если же мне нужно будет изолировать некоторые диффы (а не файлы) то, на мой взгляд, удобнее создать для них отдельную ветку. А не хранить их только локально, создавая тем самым ещё одну возможность потерять изменения навсегда, кроме "переписывания истории".

[sash-kan]

Идея принудительно добавлять каждое изменение (а не файл) показалась мне несколько странной.

повтор:

обычно, впрочем, поступают по-простому, как и в традиционных vcs-ах:
$ git commit -a
т.е., git сам найдёт все изменённые файлы, включит их в index, и на их основе будет делать commit.

часто удобнее оперировать именно файлами, а не диффами

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

Если же мне нужно будет изолировать некоторые диффы (а не файлы) то, на мой взгляд, удобнее создать для них отдельную ветку.

Тихон, именно так и делается во всех vcs. разница лишь в простоте и количестве накладных расходов на создание веток.

[watashiwa_daredeska]

Идея принудительно добавлять каждое изменение (а не файл) показалась мне несколько странной.

cat ~/.gitconfig

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

[alias]
...
  ci = commit -a

Однако, ни в одной vcs не видел такой замечательной штуки, как git'овский stash.

[t.t]

Однако, ни в одной vcs не видел такой замечательной штуки, как git'овский stash.

hg shelve

[sash-kan]

А не хранить их только локально, создавая тем самым ещё одну возможность потерять изменения навсегда, кроме "переписывания истории".

git-овский репозиторий в любом случае хранится локально. обмен информацией с другими репозиториями — это совершенно отдельный разговор.
«переписывание истории» — штука, imho, опасная и вредная. я лично никогда не переписываю. надо откатить commit в репозитории — просто делаю контр-коммит: http://book.git-scm.com/4_undoing_in_git_-...and_revert.html

по поводу git-овского index-а, как промежуточного псевдо-репозитория, споры, вероятно, не утихнут никогда. можно им пользоваться, можно игнорировать его существование.

[t.t]

А не хранить их только локально, создавая тем самым ещё одну возможность потерять изменения навсегда, кроме "переписывания истории".

git-овский репозиторий в любом случае хранится локально. обмен информацией с другими репозиториями — это совершенно отдельный разговор.

Спасибо за поправку. Привычка со времён cvcs.

«переписывание истории» — штука, imho, опасная и вредная. я лично никогда не переписываю. надо откатить commit в репозитории — просто делаю контр-коммит: http://book.git-scm.com/4_undoing_in_git_-...and_revert.html

по поводу git-овского index-а, как промежуточного псевдо-репозитория, споры, вероятно, не утихнут никогда. можно им пользоваться, можно игнорировать его существование.

А это и есть наиболее принципиальные отличия. Остальное либо сугубо косметическое, либо существует в виде "расширений", как в примере выше.

[sash-kan]

Остальное либо сугубо косметическое, либо существует в виде "расширений", как в примере выше.

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

[sash-kan]

это и есть наиболее принципиальные отличия

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

p.s. кстати, как у mercurial обстоит дело с chunk-ами? беглый осмотр гугля приводит к расширению mq, но, судя по описанию, это совершенно не то.

[sash-kan]

кстати, насколько я понимаю, работа с chunk-ами и существование index-а связаны неразрывно.
продемонстрирую примером:
1.1. я внёс изменение в файл1.
1.2. я внёс связанное с ним изменение в файл2.
2.1. я припомнил, что давно надо бы подправить один момент в файл1, что и делаю.
2.2. вношу связанное с ним изменение в файл2.

итого получается по два изменения в двух файлах.
насколько просто я смогу в том же mercurial-е занести их двумя отдельными коммитами? чтобы в первом коммите были 1.1 и 1.2, а во втором 2.1 и 2.2?
почему хочется отдельными? потому что 1.* никак не связаны с 2.*.