Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 131
Когда мне самому пришло время сделать выбор, я тоже пришёл к тому, что Merculial удобнее и логичнее для меня, как говорится «ложиться в руку». Но определённое давление со стороны сообщества (подавляющее большинство проектов, которые мне интересны, используют git в общем и github в частности) заставило «смириться» и перейти на git.
Я это говорю не с целью продемонстрировать слабость своей воли ;) Скорее, чтобы сказать, что давайте уже программировать, а не играться с системами контроля версий.
Я это говорю не с целью продемонстрировать слабость своей воли ;) Скорее, чтобы сказать, что давайте уже программировать, а не играться с системами контроля версий.
Я был бы согласен, если бы не убогость и неудобство использования меркуриала с ветками вообще.
И единственное достоинство — принудительный трекинг ветки — решается административным способом — заставлением писать номер бага в комментариях.
И единственное достоинство — принудительный трекинг ветки — решается административным способом — заставлением писать номер бага в комментариях.
По-моему в последних версиях меркуриала на уровне ядра существует поддержка т.н. bookmarks — аналог веток гита. А так, плюсы гита — скорость, плюсы меркуриала — питон (то есть, в теории лучшая переносимость… хотя на практике проблемы все-равно есть).
ммм… а что не так с ветками в hg? в чем убогость?
тем более, что ветки из git с недавних пор там тоже есть (bookmarks)
можно выбирать, какой подход использовать.
rebase тоже есть, если очень нужно.
тем более, что ветки из git с недавних пор там тоже есть (bookmarks)
можно выбирать, какой подход использовать.
rebase тоже есть, если очень нужно.
Пожалуйста, поясните, что вы имеете в виду под словами «убогость и неудобство использования меркуриала с ветками вообще».
Мне кажется, имеется ввиду то, что меркуриал явно хранит информацию о ветке, то есть ее нельзя просто закрыть путем мержа с другой веткой. Тогда как в гите ветка — просто набор изменений. Кому-то это нравится, а кому-то нет :-)
В меркуриале есть несколько способов работы с ветками (в git я знаю только два, в Hg — по меньшей мере 4, включая те, что есть в git).
В принципе, когда я начинал знакомиться с Hg там действительно было похуже с ветками, чем в Git. Но это было года два, а то и три назад.
В принципе, когда я начинал знакомиться с Hg там действительно было похуже с ветками, чем в Git. Но это было года два, а то и три назад.
достаточно просто метить тегами сборки в релизных ветках, тогда будет ясно что и когда изменилось с последней сборки. Без этого, действительно, возникает путаница при слияниях
Автор сего опуса не осилил тэги. Cool story bro.
У Git-а есть GitHub и огромная комьюнити.
У самого почему-то сердце больше лежит к меркуриалу, но простота пользования github'ом просто подкупает.
Да и для компании сейчас рассматриваем покупку GitHub Enterprise со всеми его фичами.
У самого почему-то сердце больше лежит к меркуриалу, но простота пользования github'ом просто подкупает.
Да и для компании сейчас рассматриваем покупку GitHub Enterprise со всеми его фичами.
варианты:
— новый сервис для hg, аналогичный github
— github введет поддержку hg
— hg так и останется, более удобным, но менее распространенным
— новый сервис для hg, аналогичный github
— github введет поддержку hg
— hg так и останется, более удобным, но менее распространенным
А чем bitbucket не аналог github? Да, менее фичастый, но тем не менее (плюс теперь пилится atlassian).
Ну и субъективно, мне hg не кажется более удобным, чем git.
Ну и субъективно, мне hg не кажется более удобным, чем git.
гм, а там есть аналог гитхаб энтерпрайз? сходу не наткнулся.
По-моему нет (скорее всего пока). А чем для энтерпрайза не подходят платные аккаунты с закрытыми репозиториями? Ведь все данные летают по ssh.
Дело в том, что политика компании, с которой я сейчас работаю (онлайн бухгалтерия) не позволяет хранить исходники где-то кроме своих дата серверов. И это одно из требований клиентов (тот же BDO проводит мониторинг безопасности компании).
Даже из дома нельзя работать с сорсами :)
В данной ситуации GitHub Enterprise является очень хорошим решением.
К сожалению большинство альтернатив не позволяют «хостить» их систему у себя, не считая opensource-вариантов (типа Gitorious), но компания не имеет желания тратить ресурсы на сопровождение системы, и нужен полноценный коммерческий саппорт.
Даже из дома нельзя работать с сорсами :)
В данной ситуации GitHub Enterprise является очень хорошим решением.
К сожалению большинство альтернатив не позволяют «хостить» их систему у себя, не считая opensource-вариантов (типа Gitorious), но компания не имеет желания тратить ресурсы на сопровождение системы, и нужен полноценный коммерческий саппорт.
Вот зануды :-) Но я думаю, что атлассиан со временем должен что-нибудь выкатить для таких компаний. Не зря ведь они битбакет покупали.
Есть Kiln от FogCreek. Мне кажется вполне себе подходит под ваши требования.
Когда я давно смотрел на это, мне показалось, что это какая-то обертка вокруг меркуриала (а не просто сайт). Или я плохо смотрел?
Плохо смотрели наверное.
Там есть как обертка, так и интегрированный багтрекер.
Ну и бонусы в виде коментов и всего прочего. Собственно там есть демо, и
Там есть как обертка, так и интегрированный багтрекер.
Ну и бонусы в виде коментов и всего прочего. Собственно там есть демо, и
The Fog Creek Promise
If you’re not satisfied, for any reason, within 90 days you get a full refund, period, no questions asked. We don’t want your money if you’re not amazingly happy.
тем что не многие хотят хранить код на чужом сервисе. Политика безопасности же.
Есть же bitbucket.org!
есть, я сам его юзаю
но по удобности и раскрученности он явно не дотягивает до github, к сожалению.
но по удобности и раскрученности он явно не дотягивает до github, к сожалению.
Не могли бы Вы перечесть те явно необходимые в работе удобства без которых Вам так жаль?
И причем тут раскрученность?
И причем тут раскрученность?
вроде по фичастости они практически равны
а так остается более приятный и удобный интерфейс, багтрекер, скорость и стабильность работы сайта. Что для удобства работы с сервисом решает.
раскрученность при том, что если бы не github, то hg сейчас бы был более распростанен (вероятно). Github это локомотив git.
а так остается более приятный и удобный интерфейс, багтрекер, скорость и стабильность работы сайта. Что для удобства работы с сервисом решает.
раскрученность при том, что если бы не github, то hg сейчас бы был более распростанен (вероятно). Github это локомотив git.
Не вижу, чем использование BitBucket принципиально отличается от GitHub (по простоте). И платные аккаунты там тоже есть.
Еще можно посмотреть на Atlassian Stash, аналог гитхаб ентерпрайз, но с меньшими ограничениями и по более вменяемой цене.
«Самое печальное, что большинство пользователей Git, похоже, имеют концептуальный блок против даже признания того, что здесь есть проблема.»
Действительно. Сколько лет пользуюсь всякими репозитариями, первый раз вижу такие запросы. 1 — обычно список изменений пишется по багтрекеру. По логу репозитария тоже можно, но зачем при этом видеть, в какой ветке писался фикс? Просто просматривается список коммитов в ветке, не важно, откуда они замержены. 2-3 — тоже какое-то надуманное. Мерж надо верифицировать в совокупности (всю его разницу с целевой веткой), а не по принципу «вот эти строчки — они приехали из другой ветки, поэтому их не верифицируем». Начинать новую ветку никогда не было нужно было «оттуда же, откуда другую», а с головы или с определённого известного коммита. Ну и, естественно, есть такая вещь, как теги.
Действительно. Сколько лет пользуюсь всякими репозитариями, первый раз вижу такие запросы. 1 — обычно список изменений пишется по багтрекеру. По логу репозитария тоже можно, но зачем при этом видеть, в какой ветке писался фикс? Просто просматривается список коммитов в ветке, не важно, откуда они замержены. 2-3 — тоже какое-то надуманное. Мерж надо верифицировать в совокупности (всю его разницу с целевой веткой), а не по принципу «вот эти строчки — они приехали из другой ветки, поэтому их не верифицируем». Начинать новую ветку никогда не было нужно было «оттуда же, откуда другую», а с головы или с определённого известного коммита. Ну и, естественно, есть такая вещь, как теги.
Меня всегда удивляло, как люди, приближенные к IT и знающие английский язык лучше обычных людей, умеют коверкать обычные слова так, как обычный человек никогда не додумается. Я пока таких слов наблюдаю два: хИдер и репозитАрий.
Прочитав незнакомое доселе слово header, обычный человек скорее всего прочитает это правильно (как хэдэр), потому что знает как читается слово head. От половины знакомых сишников\сиплюсистов я слышу убийственное «хидер». Но в принципе за это еще можно простить — произношение буквосочетания «ea» является одним из самых аномальных в английском языке (deal — ди: л, deaf — дэф, great — грейт и т.д.).
Но откуда взялась эта пошесть с «репозитАриями»? Снова же, обычный человек, увидев это слово впервые, скорее всего прочитает буква в букву «репозиторий». И хоть он будет не совсем прав (правильное произношение слова — рэ'пазитори, с ударением на второй слог), но будет гораздо ближе.
И я был бы очень рад, если хоть один человек, прочитав этот комментарий, станет произносить эти слова верно.
Прочитав незнакомое доселе слово header, обычный человек скорее всего прочитает это правильно (как хэдэр), потому что знает как читается слово head. От половины знакомых сишников\сиплюсистов я слышу убийственное «хидер». Но в принципе за это еще можно простить — произношение буквосочетания «ea» является одним из самых аномальных в английском языке (deal — ди: л, deaf — дэф, great — грейт и т.д.).
Но откуда взялась эта пошесть с «репозитАриями»? Снова же, обычный человек, увидев это слово впервые, скорее всего прочитает буква в букву «репозиторий». И хоть он будет не совсем прав (правильное произношение слова — рэ'пазитори, с ударением на второй слог), но будет гораздо ближе.
И я был бы очень рад, если хоть один человек, прочитав этот комментарий, станет произносить эти слова верно.
Возможно, они путают репозиторий с депозитарием.
Ух, я как раз всегда говорил «хидер», надо же. Спасибо)
Высший пилотаж произносить «сустем» и «экзишник»
Высший пилотаж — это читать по правилам французского или немецкого языка без запинок ;)
Мой личный эталон — «канцель» («cancel»).
Я тоже так часто говорил, сейчас «по-русски» читаю как-то посередине между, т.е. «кансель».
У нас препод в универе говорила «цанцэл» :)
Сам всегда так же произношу :-)
Вообще, замечаю: если английское слово произнести по правилам чтения немецкого языка — его написание легче воспринять на слух, и меньше вероятность исказить его на письме. Особенно, когда собеседнику это слово незнакомо.
Вообще, замечаю: если английское слово произнести по правилам чтения немецкого языка — его написание легче воспринять на слух, и меньше вероятность исказить его на письме. Особенно, когда собеседнику это слово незнакомо.
Во времена приставок Dendy одну из управляющих кнопок на джойстике некоторые деятели называли «Селест» («Select»).
У меня в институте преподаватель СИ говорил пьЮблик
В словарях есть оба варианта (с О и с А). И вообще, это устоявшийся программистский сленг. Если говорить по русски, то и «мерж», и «верифицировать», и «теги», и «лог», и «багтрекер», и «фикс», и «коммит» употреблять нельзя. И если я напишу всё на великорусском, коллеги будут читать мой пост в два раза дольше.
В некоторых (очень немногих) словарях действительно есть оба варианта, большинство других указывают исключительно вариант через О. Также Википедия и Гугл. Возможно, у произношения слова как «репозитарий» есть какое-то оправдание, но всё же лучше, как мне кажется, использовать общепринятый вариант. Мне лично оно уж совсем режет слух.
Те другие слова, что вы написали, я тоже использую каждый день. Это обычные кальки с английских слов, и это их большой плюс. Я совсем не за перевод всех терминов на русский, абсолютно наоборот — калькирование уменьшает различие между языками, позволяя людям разных национальностей проще общаться. У меня друг работает в Ubisoft и ему часто приходится сталкиваться с французской документацией или общаться с главным офисом — так вот, во французском практически все технические термины были переведены, и это ужасно — их все нужно учить с нуля.
Всё, что я хотел написать — это что калькировать нужно с сохранением исходного звучания, ну или хотя бы не додумывать своих звуков. Ведь еще существуют люди, которые произносят browser как «броузер».
Те другие слова, что вы написали, я тоже использую каждый день. Это обычные кальки с английских слов, и это их большой плюс. Я совсем не за перевод всех терминов на русский, абсолютно наоборот — калькирование уменьшает различие между языками, позволяя людям разных национальностей проще общаться. У меня друг работает в Ubisoft и ему часто приходится сталкиваться с французской документацией или общаться с главным офисом — так вот, во французском практически все технические термины были переведены, и это ужасно — их все нужно учить с нуля.
Всё, что я хотел написать — это что калькировать нужно с сохранением исходного звучания, ну или хотя бы не додумывать своих звуков. Ведь еще существуют люди, которые произносят browser как «броузер».
Но откуда взялась эта пошесть с «репозитАриями»?
Пишу «репозиторий» — спеллчекер предлагает «депозитарий», соответственно думаю, что писать нужно «репозитарий» рассчитывая, что правило заимствования одно и тоже.
Мицголь?
Помойму, слово «репозитАрий» куда как старше всего этого нашего айти, оно означает «хранилище». Но интернеты пришли с айтишниками — понятно, почему в гуглопоиске слово репозитОрий ищется чаще. Гуглопоиск — не гарант исторической справедливости.
Спс, чувак. Узнал, что хедер, а не хидер
Честно говоря, раскрашенные вершины совершенно не помогают понять, откуда взялась, например, ветка release: из master или temp. Если в Git делать обычные слияния из двух источников и продолжать только одну ветку (а зачем вам больше), то никакого различия нет. И аргумент про rebase в локальном репозитории какой-то надуманный…
Git и Mercurial это одно и то же по сути, только у первого искаропки куча фич, которые в последнем надо включать в конфиге, вот и вся разница.
Mercurial это казуальная версия Git, так сказать на пальцах.
Mercurial это казуальная версия Git, так сказать на пальцах.
Можете ли вы мне сказать, на какую ветку было зафиксировано изменение ab3e2afd?
for i in `git show-ref --heads --dereference --hash`; do
if [ `git rev-list ab3e2afd ^$i | wc -l` -eq 0 ]; then
echo "`git describe $i` includes the change ab3e2afd";
fi;
done
Ок. У меня есть три ветки: интеграционная, для выкладки на тестовые стенды, для выкладки в продакшин. 90% коммитов попадают во все три. Как прикажете красить?
По-моему единственная проблема git — это сложность.
Начать действтвительно эффективно им пользоваться без старах выстрелить себе в ногу (и своим коллегам) можно только после того, как прочтешь хороший кусок документации и поймешь его архитектуру, которая, на мой взгляд, предельно осмысленная и в дополнениях уже не нуждается.
Начать действтвительно эффективно им пользоваться без старах выстрелить себе в ногу (и своим коллегам) можно только после того, как прочтешь хороший кусок документации и поймешь его архитектуру, которая, на мой взгляд, предельно осмысленная и в дополнениях уже не нуждается.
> По-моему единственная проблема git — это сложность.
Git простой и предельно логичный в своей архитектуре. Сложности и магия возникли тогда, когда попытались сделать «как в свн», тут-то абстракции потекли.
Git простой и предельно логичный в своей архитектуре. Сложности и магия возникли тогда, когда попытались сделать «как в свн», тут-то абстракции потекли.
Магия возникает еще и при использовании чисто git'овых средств, вроде удаления ветки на удаленном репозитории или переключение веток при незакоммиченных изменениях. Как это работает не очень понятно, если не знать про index, working directory, bare репозитории, pull/fetch и тп.
То есть, чтобы просто не попротить все нужно знать как гит устроен. Это проблема. Вы же не изучаете устройство чайника, чтобы им пользоваться.
То есть, чтобы просто не попротить все нужно знать как гит устроен. Это проблема. Вы же не изучаете устройство чайника, чтобы им пользоваться.
у тебя в конфигах косяк
branch..remote
When in branch, it tells git fetch and git push which remote to fetch from/push to. It defaults to origin if no remote is configured. origin is also used if you are not on any branch.
выполни: git config branch.master.remote origin
branch..remote
When in branch, it tells git fetch and git push which remote to fetch from/push to. It defaults to origin if no remote is configured. origin is also used if you are not on any branch.
выполни: git config branch.master.remote origin
почему недостаточно просто push/pull (в hg этого достаточно)
Из репа созданного hg init — недостаточно. А из склонированного репа git тоже умеет pull/push без лишних слов.
Вообще моё впечатление такое, что у пользователей меркуриала проблемы с пониманием концепции staging area.
если это вы лично обо мне
Боже упаси, я вас первый раз вижу (:
staging area — это кастрированные managed queues.
managed queues как вы их назвали, это quilt приделанный на скотче к меркуриалу.
А staging area — это средство отделения мух от котлет — всех изменений в воркдире от изменений с которыми мы собираемся сейчас что-то сделать.
Ну и выстрелишь себе в ногу, и что? Откатишь назад. Запороть что-то необратимо случайно — очень маловероятно, для опасных операций надо всякий --force писать, т.е. это делается очень редко и 7 раз подумав и сделав резервную копию.
git чуть-чуть сложнее в освоении, чем, скажем, svn, но невероятно проще в жизни.
git чуть-чуть сложнее в освоении, чем, скажем, svn, но невероятно проще в жизни.
Ой, а в mercurial уже есть аналоги git add -p, git rebase -i и git reflog?
add -p всю жизнь был hg record, reflog тоже есть, причем reflog интегрирован в битбакет (форма поиска по репозиторию умеет его синтаксис), rebase не пользуюсь, не знаю, может и нет
А ваш hg rebase ханки редактировать умеет, как git add -p / -i
Тьфу, hg record имел в виду. Вижу что вроде нет, минимальная единица редактирования коммита — один ханк. А мельче можно? У git add -p есть среди вариантов 'e', который вызывает $EDITOR в котором ханк-кандидат можно FUBAR отредактировать как нужно.
rebase есть.
Очень надуманно… у нас в день валится пара десятков изменений в ветках, которые частично уходят на продакшн, частично на текущий релиз… Если вы наворотили делов, напишите гайд по веткам на страничку, и уже завтра все будет выглядеть идеально. Цветная раскраска, и что? GitX, GitGui тоже раскрашивают ветки.
Это всё очень религиозно. Наша команда, например, разделилась на две части — одна говорит, что гит — непонятная поделка, другая же, что меркуриал. И у всех есть свои основания так говорить. Не надо ничего сравнивать, нужно использовать то, что нравится для своих проектов и то, что придётся для проектов, где вы не решаете таких вопросов или их даже не надо решать (сложность переезда, невозможность выделения времени на это и т.п.)
Не очень понимаю комментаторов.
Ключевое различие git и mercurial — это подход к слиянию веток. В mercurial нельзя несколько веток слить в одном коммите и это очень правильно! Никакой путаницы, всё под контролем, всё последовательно. А после мегамёрджа в git никто ничего никогда уже не разберёт.
Ключевое различие git и mercurial — это подход к слиянию веток. В mercurial нельзя несколько веток слить в одном коммите и это очень правильно! Никакой путаницы, всё под контролем, всё последовательно. А после мегамёрджа в git никто ничего никогда уже не разберёт.
Засранцы, Линус ждет ваших патчей мердж реквестов.
Появился интересный ответ на оригинальную статью — felipec.wordpress.com/2012/05/26/no-mercurial-branches-are-still-not-better-than-git-ones-response-to-jhws-more-on-mercurial-vs-git-with-graphs/
Немного не удобно пользоваться git name-rev для каждой ревизии, поэтому я написал свой хук, который автоматически добавляет в коммит мессадж информацию о названии ветки и её описании (если доступно). Сохранил в файле .git/commit-msg:
#!/bin/sh
#
# Automatically adds branch name and branch description to every commit message.
#
NAME=$(git branch | grep '*' | sed 's/* //')
DESCRIPTION=$(git config branch."$NAME".description)
echo "$NAME"': '$(cat "$1") > "$1"
if [ -n "$DESCRIPTION" ]
then
echo "" >> "$1"
echo $DESCRIPTION >> "$1"
fi
Прошу прощения, что без форматирования — не достаточно кармы, очевидно…
#!/bin/sh
#
# Automatically adds branch name and branch description to every commit message.
#
NAME=$(git branch | grep '*' | sed 's/* //')
DESCRIPTION=$(git config branch."$NAME".description)
echo "$NAME"': '$(cat "$1") > "$1"
if [ -n "$DESCRIPTION" ]
then
echo "" >> "$1"
echo $DESCRIPTION >> "$1"
fi
Прошу прощения, что без форматирования — не достаточно кармы, очевидно…
Не смог остаться равнодушным.
Честно говоря, не нравятся обе ваши картинки. На мой взгляд, такого допускать не стоит ни в какой системе.
И то, в какой ветке было сделано какое-то изменение не имеет смысла. Имеет смысл то, в какой ветке есть это изменение, а в каких — нет.
Есть ощущение, что Mercurial круче и гибче, но из поста так и не смог вкурить чем же именно.
Как это часто бывает, пересев с Svn на Git испытал чувство экстаза. Все, что работало плохо и часто ломалось в Svn в Git просто великолепно реализовано. И сам процесс разработки с переездом на Git сразу сдвинулся с места. Конечно, ограничения ощущаешь лишь со временем, но до сих пор Git позволяет мне вести процесс разработки так, как мне нужно и удобно.
Возможно так и надо подходить к вопросу — если встают непреодолимые препятствия или существенные ограничения, то да, пора «менять кобылу». Но пока она везет и достаточно резво, какой резон пересаживаться на другую? Мне кажется в этом основная причина того, что Git — мэйнстрим. Он достаточно хорош, чтобы его использовать, а его ограничения не настолько критичны, чтобы переводить с него процесс на mercurial, в котором, кончено же, со временем тоже почувствуются свои ограничения.
Git очень гибок и в этом его минус, если не умеешь им пользоваться. Он дает огромное количество инструментов и надо их изучать.
Сейчас наш workflow построен так, что я точно знаю, где и когда было сделано то или иное изменение и когда оно выйдет в свет.
История проста и понятна и по ней я могу точно сказать, где именно был сделан тот или иной коммит и когда он попал в ту или иную ветку. Это видно по истории. Это в git решается не на уровне самой системы, а на уровне организации процесса. По крайней мере, у меня так.
Честно говоря, не нравятся обе ваши картинки. На мой взгляд, такого допускать не стоит ни в какой системе.
И то, в какой ветке было сделано какое-то изменение не имеет смысла. Имеет смысл то, в какой ветке есть это изменение, а в каких — нет.
Есть ощущение, что Mercurial круче и гибче, но из поста так и не смог вкурить чем же именно.
Как это часто бывает, пересев с Svn на Git испытал чувство экстаза. Все, что работало плохо и часто ломалось в Svn в Git просто великолепно реализовано. И сам процесс разработки с переездом на Git сразу сдвинулся с места. Конечно, ограничения ощущаешь лишь со временем, но до сих пор Git позволяет мне вести процесс разработки так, как мне нужно и удобно.
Возможно так и надо подходить к вопросу — если встают непреодолимые препятствия или существенные ограничения, то да, пора «менять кобылу». Но пока она везет и достаточно резво, какой резон пересаживаться на другую? Мне кажется в этом основная причина того, что Git — мэйнстрим. Он достаточно хорош, чтобы его использовать, а его ограничения не настолько критичны, чтобы переводить с него процесс на mercurial, в котором, кончено же, со временем тоже почувствуются свои ограничения.
Git очень гибок и в этом его минус, если не умеешь им пользоваться. Он дает огромное количество инструментов и надо их изучать.
Сейчас наш workflow построен так, что я точно знаю, где и когда было сделано то или иное изменение и когда оно выйдет в свет.
История проста и понятна и по ней я могу точно сказать, где именно был сделан тот или иной коммит и когда он попал в ту или иную ветку. Это видно по истории. Это в git решается не на уровне самой системы, а на уровне организации процесса. По крайней мере, у меня так.
Я пользовался долгое время и тем и другим. Принципиальной разницы не заметил. Декоративная разница есть, но не более того.
Хотя нет — есть разница при поведении в очень сложных ситуациях, которые сами по себе являются не допустимыми при коллективной работе. Но, с учетом того, что эти ситуации относительно редки, разница получается минимальной.
Хотя нет — есть разница при поведении в очень сложных ситуациях, которые сами по себе являются не допустимыми при коллективной работе. Но, с учетом того, что эти ситуации относительно редки, разница получается минимальной.
если вам графики цветные строить то до, пользуйтесь этим
а если работать, то всё таки git
а если работать, то всё таки git
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ещё раз о «Mercurial против Git» (с картинками)