Чем пользуется бОльшее количество людей - Git или Mercurial?

А hg имеет возможность индексирования изменений файла по частям?
Пример:
Имеется большой файл, в который ты вносишь два несвязанных между собой изменения за раз (например, фикс какого-нибудь бага и добавление новой функции); затем сохраняешь этот файл. И тут возникает желание сделать два коммита: первый - с фиксом бага, второй с добавлением функции. Как это реализовать в Mercurial (им не пользовался ни разу)?
В Git'е всё просто - git add -i.

А hg имеет возможность индексирования изменений файла по частям?

Без понятия. Я пользуюсь только hg ini, hg diff, hg st, hg addremove, hg comm, hg push.

Серьёзно? Darcs больше, чем mercurial?

Статистика сделана по всем файлам debian/control в репозитории Debian.

Надеюсь, адепты Mercurial ответят мне на этот вопрос.

А что за mtn и arch?
Кто использовал? Расскажите пожалуйста о впечатлениях/основных особенностях.

А что за mtn и arch?

mtn - это ныне покойная Monotone, Git - сильно упрощенная ее версия. Arch... об этом лучше не вспоминать.

А что за mtn и arch?

http://www.gnu.org/software/gnu-arch/

А разгадка проста - необходимо добавлять файлы в индекс.

Крайне неприятная особенность. Да там есть этот сраный карман, который иногда удобно использовать (типа прикопать не глубоко). Но это так редко надо, что как-то глупо это делать дефлотным поведением.

Там много таких упоротых моментов в синтаксисе.

Да брось, кармашек этот рулит. Как и stash'и в удобном стэке!
Без индекса - жутко неудобно, а с ним всё очевидно, только привыкнуть надо.
Да и при желании ты всегда сможешь воспользоваться своим алиасом к git commit -am.

Ага, вспомнил его.
tla же.

Я не понимаю чем он отличается от svn status. Да через stash ты можешь безопасно протаскивать измения без коммита, чего иной раз не хватает, но просто так индекс выглядит лишней сущностью.

Тем, что в Git-индекс ты можешь добавить лишь часть изменений из файла, потом присобачить к ним ещё какие-нибудь изменения и выделить это всё в один тематический коммит. Затем оставшиеся изменения выделить в другой коммит. Без отдельной сущности это было бы невозможно.

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

И что это за хрень?
Хоть одно приложение для WinRT или iOS на нём написали?

Если посмотришь сайт дольше 1 секунды, то там есть вполне рабочие штуки :)

Гдн WinRT?

Я с svn особого дела не имел. Там svn commit берёт все изменённые и добавленные файлы и отправляет на сервер? А что если сделал изменения, например, в пяти файлах и в первый коммит нужно выделить только три из них, а во второй - остальные? svn commit file1 file2 file3 а затем svn commit? В Git индекс в таком случае очень спасает. Всегда можно посмотреть, что попадает в коммит, а что остаётся. Но ещё раз повторюсь, ничего не мешает использовать SVN-политику, то есть работать вообще без индекса. И использовать что-нибудь типа git commitall в качестве svn commit и так же git commit file1 file2 file3 вместо svn commit file1 file2 file3. Разница будет лишь в одной команде, которая будет alias'ом к git commit -a.
Лично, я пришедший в Git с CVS (Concurrent Versions System), вздохнул с облегчением с появлением такой мощной сущности, как индекс. Ранее вечно коммитил что-нибудь лишнее на сервер. А с индексом - дополнительная проверка, что не закоммитишь какую-нибудь каку.

Гдн WinRT?

Что это?

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

Да вы, батенька, знатный извращенец. Может, он ещё и в разные репозитории их должен отправлять одновременно?

Это достаточно стандартная ситуация на больших проектах: пока работаешь над добавлением какого-либо функционала, в чат могут постучать и попросить быстро пофиксить баг или изменить что-то. Всё это, конечно, отправится в разные коммиты.
Вам, с дивана, видимо не приходилось бывать в такой ситуации.

Это достаточно стандартная ситуация на больших проектах: пока работаешь над добавлением какого-либо функционала, в чат могут постучать и попросить быстро пофиксить баг или изменить что-то.

Да, бывает такое. Лично я юзаю shelve. Понадобилось поработать над другим — отложил текущие изменения и работаю. Всё равно тестировать их отдельно надо перед коммитом, иначе есть шанс что одни изменения заденут другие.

http://lmgtfy.com/?q=WinRT

Это то самое, с Market Share 0.00001%?

В git для этого есть stash'и, но иногда забываешь отложить в «копилку» текущую работу перед багфиксом, особенно если он на одну-две строчки. Ну а насчёт тестов всё пушится в test/develop, а потом, как ветка достигает стабильности - master перематывается до стабильного коммита в develop.

Это то самое, с Market Share 0.00001%?

Вылезайте из танка и винимайте зонд не дающий вам нормально.

Вы писали о преносимости, но Java как оказалось мене переносима чtм C#

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

svn commit file1 file2 file3 а затем svn commit?

Да так. Сложнее если тот же файл.

Я с этим не спорю. Это приведено наобум в качестве примера. Обычно так и делаю - для каждой фичи и багфикса - отдельная ветка; но бывает что...

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

Да вы, батенька, знатный извращенец.

Меня тоже в извращенцы запиши. А то знаешь, рабочие файлы и папка test часто в одном репозитории. Вот сделал фичу, и я предпочту не делать один коммит, а рабочие файлы — в одном, тесты — в другом коммите.

Записал :)

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

Использовать для этого индекс глупо. По-хорошему, здесь нужен mq или какой-то аналог для git.

По-хорошему, здесь нужен mq

Что такое mq?

http://mercurial.selenic.com/wiki/MqExtension

Как язык или как платформа? Как язык такая же переносимость или чуть хуже, как платформа переносить в разы лучше.

Он намекает на то, что пулл должен только подтягивать (что и означет слово pull)

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

Ясно, костыль вследствие отсутствия индекса. У MQ не понравилось, что нужно заранее определять, над какой фичей работаешь, чтобы создать патч. В то время как с git просто редактируешь файлы, а потом определяешь, какие изменения коммитить.

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

Это ты про Торвальдса?

Я же говорю, это наверное дело привычки. Я начал с меркуриала, поэтому никак не могу привыкнуть понимать pull как «pull & update».

Ясно, костыль вследствие отсутствия индекса

Типичная ошибка гит-фанбоя.

У MQ не понравилось, что нужно заранее определять, над какой фичей работаешь, чтобы создать патч. В то время как с git просто редактируешь файлы, а потом определяешь, какие изменения коммитить.

И еще одна.

Это ты про Торвальдса?

согласен, перегнул )))

А сказать по существу что-нибудь есть? Или линк хотя бы. Я вон в нет залез, почитал http://pqr7.wordpress.com/2011/01/07/a-git-users-guide-to-mercurial-queues/ и сделал выводы. Т.е. с MQ у тебя всегда конкретное число патчей. Решил добавить один, а в конце работы оказалось, что лучше было бы сделать их два. Как выходить из положения? Или ты заранее точно знаешь, сколько из нужно? Вот с git таких проблем не может быть в принципе.

Еще раз глянул на http://pqr7.wordpress.com/2011/01/07/a-git-users-guide-to-mercurial-queues/ Идея патчей внутри патчей, коммитов для патчей, pull/push для патчей — здорово!

Я так и не понял, как в этом чертовом гите делать commit: пишет мне постоянно, что хрена с два! Мол, вызывай commit -a, вот и приходится -a добавлять. А в mercurial все чисто и понятно. И не надо команды целиком писать, как в гите!

А в гите ещё проще: двойной клик по файлу vesj_proekt_v_komment.sh и процесс пошёл! И от мусора почистит, и прочее сделает.

А то знаешь, рабочие файлы и папка test часто в одном репозитории. Вот сделал фичу, и я предпочту не делать один коммит, а рабочие файлы — в одном, тесты — в другом коммите.

Есть hg shelve, но зачем фича в одном, а тесты в другом? Почему их нельзя совместно коммитить?

Как язык или как платформа?

А что, есть платформа C#?

Есть hg shelve

Как он решит задачу, когда нужно сделать коммит только из _части_ изменений?

но зачем фича в одном, а тесты в другом? Почему их нельзя совместно коммитить?

Это только как наиболее показательный пример, когда нужно коммитить только часть изменений. Если бы этого не было нужно, как утверждает товарищ vurdalak, то не было бы Mercurial Queues Extension.

Как он решит задачу, когда нужно сделать коммит только из _части_ изменений?

Ты привёл пример, где изменения строго разнесены по файлам (тесты/не тесты).

Если требуется ещё большая гранулярность, есть hg record или crecord.

Если бы этого не было нужно, как утверждает товарищ vurdalak, то не было бы Mercurial Queues Extension.

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

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

Щито ви говорите! Этого ф-ционала у меркуриала нет, поскольку отсутствует индекс, как в гите.

Щито ви говорите! Этого ф-ционала у меркуриала нет

Какого фционала нет?

Имею в виду, у меркуриала без расширений. Короче, Mercurial Queues Extension — это расширение, потому что его нельзя реализовать иначе. Компрене?