Не, всё-таки при всех своих некоторых преимуществах, Mercurial - ТОРМОЗ.

[poige]

(По сравнению с Git).

Comments

Re: преимуществах, Mercurial... По сравнению с Git.

[mpd]

А какие самые важные преимущества у Mercurial по сравнению с Git, по-вашему?

> А какие самые важные преимущества у

[poige]

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

Например: hg incoming → git ?

Re: Просто hg больше для людей, вот по мелочи и набирается

[mpd]

А как понять "hg больше для людей"?
Это противопоставление второму, т.е. "git - для крсноглазиков"?

> т.е. "git - для крсноглазиков"?

[poige]

Нет, просто mercurial зачастую более удобен в использовании.

Re: > А какие самые важные преимущества у

[ext_47000]

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

git fetch origin; git log branchname..origin/branchname

> показать какие коммиты есть в ветке

[poige]

Ага, спасибо!

Ещё один пример, который показывает почему у hg репутация «больше для людей», чем у git. :-)

Re: > показать какие коммиты есть в ветке

[ext_47000]

на самом деле все просто - просто git работает в терминах деревьев, веток - все что вышеприведенная команда делает - показать разницу между двумя деревьями (узел дерева - коммит). К этому на самом деле быстро привыкаешь и это даже удобно :)

> на самом деле все просто - просто git работает

[poige]

Ага, а ещё ci работает по умолчанию, а для git нужно прописать alias. И всё в таком духе.

Re: > на самом деле все просто - просто git работает

[nikita_timofeev]

Ну... С git'ом поставляются очень не плохие bash-completion'сы. А вообще все знакомые мне "люди" использующие git, используют самописные скриптовые обёртки вокруг него. Самые частые претензии, которые мне доводилось слышать в адрес гита: отсутствие докачки; отсутствие какой либо libgit.so и... невозможность ограничить доступ части разработчиков к части репозитория. Последние как правило выбирают svn.

> Ну... С git'ом поставляются очень не плохие bash-completion'сы

[poige]

Не понял, вы оспариваете тот факт, что hg «более для людей», чем git?

> невозможность ограничить доступ части разработчиков к части репозитория

Какой доступ - на чтение, или на запись?

Re: > Ну... С git'ом поставляются очень не плохие bash-completion'сы

[nikita_timofeev]

Скорее мне не понятна аргументация. Почему hg «более для людей»? То что он медленнее мне понятно. То что для работы с ним мне потребуется питон (которого в системе-на-флешке я предпочёл бы не иметь в виду размера) мне тоже понятно. А вот чем он удобнее гита мне как-то не очень понятно. На мой взгляд то же самое вид с боку. К слову и git fetch и git log (и ещё много кто) прекрасно работают и без указания конкретного дерева.

> Какой доступ - на чтение, или на запись?

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

> Скорее мне не понятна аргументация.

[poige]

Ну и ладно. ;-)

> именно о невозможности закрытия части репозитория на запись.

Без проблем - в Git есть hook'и (как и в SVN, к примеру), поэтому - без проблем.

> git log branchname..origin/branchname

[poige]

Кстати, вот только что проверил на clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git:

$ git b
* (no branch)