Previous Entry Share Next Entry
2016-01

git vs mercurial

Накопился определенный опыт работы с одним и с другим.

В общем:
Git: it works, but you have to learn it, tune it and tweak it.

Mercurial: it just works. you can tune it if you want, but it just works.

Еще с гитом я успел повлетать в пачку неприятных моментов когда пуш/пулл тупо не проходили, или репозиторий корраптился. Хорошо, что есть reflog.

Плюс, как показала практика, в меркуриал можно успешно засунуть TFS репозиторий с историей весом несколько Gb, и это не вызывает каких-то тормозов вообще. Очень, очень хорошо. Да, не факт что это нормальная ситуация, но легаси есть легаси, его не изменить.

В гите такое же действие приходит к тому что эмм надо долго шаманить с настройками, прежде чем пройдут особо крупные коммиты. Можно? Можно. Удобно? Не очень.

Хотя "непроходимость коммитов" случалась даже на мелких репозиториях, если делать рефакторинг.

С меркуриалом "history is sacred". Кому-то это нравится, кому-то нет. Мне - нравится.

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

Итого, для себя для продакшена - меркуриал. Гит неплох, но отвлекает. Меркуриал - просто и естественно становится частью рабочего процесса.

Плюс, "windows is a first-class citizen for mercurial". Hg Workbench на первый взгляд страшен, но уже через пару дней реально удобная тулза. Тестеров и джуниоров она тоже не пугает, что немаловажно.

А, да. SVN остается для особо сикретне проектов, где важна необходимость ограничивать доступ с гранулярностью до папок и оправдан оверхед на неудобные мержи.

Как-то вот так.

This entry was originally posted at http://wizzard.dreamwidth.org/251661.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
fi_mihej November 22nd, 2012
А до того, как хорошо поюзал оба, что ты думал на эту тему, интересно? (просто не помню)

wizzard0 November 22nd, 2012
Ничего не думал

maxim November 22nd, 2012
Для меня гит это прежде всего гитхаб.

wizzard0 November 22nd, 2012
Бесспорно. Гит живет благодаря Линусу и гитхабу.

nponeccop November 22nd, 2012
плюсую.

bik_top November 22nd, 2012
Меркуриал — он как гит, только для людей.

> Hg Workbench на первый взгляд страшен, но уже через пару дней реально удобная тулза.

Это ещё что. До того, как его переписали с GTK+ на Qt он был реально чудовищен.

mykolad November 23rd, 2012
Ну не совсем. Я еще помню Workbench маленьким-маленьким. Вот когда в него засунули и коммиты и синхронизацию, он действительно стал страшным, как сейчас. Впрочем, привыкнуть можно.

osdm November 22nd, 2012
Hg Workbench нереально тормозит на нашем репозитории. Говорят, он на любое нажатие запрашивает статус. Не знаю. Но факт в том, что он это для многих операций делает не в фоне, а в UI, подвисая на каждое действие пользователя, даже элементарные вроде переключения на таб другого репозитория или вызов контекстного меню на файле. А вызов Shelve - это вообще особое удовольствие. В общем, без SSD лаги на любую операцию по 30-60 сек, да и с SSD тоже по 5-20 сек бывают.

А еще эти особо умные люди не предусмотрели прямого способа связать переименованные файлы. Казалось бы, берешь отсутствующий в FS файл и новый файл, селектишь и нажимаешь пункт меню - так нет, только через интерфейс автоопределения, который сначала будет угадывать, что с чем связать, и только потом разрешит выбрать из угаданных вариантов. Очень дружественно.

max630 November 22nd, 2012
Специально для таких случаев там есть терминал в меню

orlangur_8eyed November 22nd, 2012
Там можно по удалённому файлу правой кнопкой щёлкнуть и выбрать, во что он был переименован.

osdm November 22nd, 2012
Я так и делаю. Из чего-то похожего вижу только пункт Detect Renames, который и запускает тот самый гребанный интерфейс автоопределения. Может, я что-то пропустил?

osdm November 23rd, 2012
Искреннее человеческое спасибо (за коммент, который в скрине). Was renamed from действительно существует у нового файла. Совершенно неочевидно, но, по крайней мере, возможность есть.

max630 November 22nd, 2012
> С меркуриалом "history is sacred". Кому-то это нравится, кому-то нет. Мне - нравится.
> Гит, напротив, должен быть приятен тем, кто подрабатывает в министерстве правды и правит коммиты задним числом.

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

wizzard0 November 22nd, 2012
> Функционала для ребейза в hg не меньше, и он постоянно дописывается.

Ненене, я про другое.
I'm fine with rebase of unpublished commits, нервирует меня в основном git filter-branch && git push -f

max630 November 22nd, 2012
git filter-branch - это совсем тяжелая артиллерия. Она нужна очень редко. Например у меня есть либа, и я её выделяю в отдельный проект. Зачем тащить для этого историю всего проекта.

maxim November 22nd, 2012
я могу выделить либу в отдельный проект за 15 минут в CVS, SVN и в чем угодно :-)

avnik November 22nd, 2012
Не, у тебя в проекте есть
src/libfoo которую ты хочешь вынести в отдельный репозиторий.
Со всей историей коммитов.
1 ты его клонишь
2 выпиливаешь все не относящееся к делу filter-branch'ем
3 избавляешься от src/libfoo в именах (по моему передвинуть в первом коммите при ребейсе будет достаточно)

maxim November 22nd, 2012
я могу без фильтер бренча сделать это в любой VCS :)

avnik November 22nd, 2012
И как же это интересно?

fi_mihej November 23rd, 2012
Ну мы ж программисты: неуж-то метод не придумать, коли надо :)

fi_mihej November 23rd, 2012
Не, ну собственный скриптик, естессно и не такое сделает. Но тут вроде-как за встроенную фичу ветка идет.

ЗЫ: я - Mercurial-фан, если чо. И за гитовский "filter-branch" - не копенгаген.

avnik November 22nd, 2012
Еще как-то фильтр был полезен, когда мне надо было сливаться с веткой одного деятеля у которого в редакторе были табы вместо пробелов (петон ага).
Профильтровал все его коммиты умным скриптом, а потом оно все корректно смержилось

spiculator November 22nd, 2012
А почему просто не сделать один коммит, который заменяет все табы на пробелы? Зачем нужно, чтобы в истории тоже пробелы были?

avnik November 22nd, 2012
потому что гражданин упорно не хотел настраивать редактор, и мне регулярно сливаться с ним надо было. И иногда допиливать его ветку перед влитием (коммиты разделять например -- чувак атомарностью не парился, а говнокод иногда приходилось ревертить)

mykolad November 23rd, 2012
А еще неправильный rebase это отличный способ угробить репозиторий Mercurial. У меня в прошлом было много-много таких случаев.
Если уж приходится делать rebase, очень желательно перед этим сделать копию всего репозитория на диске. На всякий случай, так сказать.

fi_mihej November 23rd, 2012
Бекап - это да - это всегда полезно )

Сергей Шиков November 22nd, 2012
Кстати, попытки импортировать в Git репозиторий довольно тяжелого проекта из SVN не привели ни к чему.

Все тормозило настолько, что импорт не завершался за сутки. С hg тоже самое прошло довольно быстро - час или вроде того. То есть разница была как минимум на порядок/два.

Инструменты для импорта - пробовал все, какие тогда нашел.

wizzard0 November 22nd, 2012
Ага, аналогично.

mykolad November 23rd, 2012
На прошлой работе мы импортировали SVN репозиторий почти 20-летней давности с 40к коммитов в Mercurial. В принципе, все прошло без накладок. Правда, если пытаться работать с репозиторием Mercurial, чтобы можно было назад в SVN запушать, тут уж начинается ад (rebase и все такое).
В общем, если переходить на Mercurial с SVN, то уж сразу и навсегда.

fi_mihej November 23rd, 2012
Просто тут хитрость нужна: импортируем из svn-сервера - в default бранч hgsubversion-ом. Делаем изменения в каких-то других бранчах. Экспортируем изменения в бранч с папочкой .svn, и коммитим тортойз-svn-ом. hg pull. Начинаем сначала :)

fi_mihej November 23rd, 2012
И никаких ребейзов. И история коммитов - нормальная - ветвистая :)

109 November 24th, 2012
о, а мне надо импортировать из SVN в TFS. такие тулзы бывают?

kurilka November 22nd, 2012
Я не особый юзер hg, но я правильно понимаю, что термином hg workbench накой-то tortoisehg обзываете? Это чтоб никто не догадался?

orlangur_8eyed November 22nd, 2012
Да, TortoiseHg Workbench — GUI для Mercurial. Но TortoiseHg — это не только Workbench.

wizzard0 November 22nd, 2012
Workbench - это штука, которая положительно отличает TortoiseHg от остальных Tortoise*

Поэтому я упоминаю именно его, а не черепаху.

ens_a_se November 22nd, 2012
Git от меня потребовал столько же усилий, сколько изучения утилит юникска (grep, cut, find,...) потому что в git очень уж дофига комманд разных. Притом всякие редкие комманды я зыбываю/изучаю с периодом полгода. Я вот честно не уверен, что cherry-pick - нужная вещь, мне видится как сахарок какой-то. В Mercurial столь же много комманд?
Но с git нельзя не дружить потому что github - ну понимаешь, он такой ня-ня.

gds November 22nd, 2012
а чего бы не дружить с гитхабом через меркуриаловское расширение hg-git?

nponeccop November 22nd, 2012
Я так и не разобрался, как с hg-git работать. Скажем, есть три репоза (мой локальный hg, мой форк в гитхабе и апстрим). Я клонирую версию 1.0 апстрима на гитхабе, клонирую мой гитовский репоз к себе в меркуриал, патчу и заливаю свои изменения к себе в гитхаб. Выходит версия 2.0, и я хочу перенести свои коммиты поверх 2.0 и отправить апстриму пулл-реквест. Т.е. было

1.0 - Мои коммиты

Стало

1.0 - коммиты апстрима - 2.0 - мои коммиты

Это противоречит history is sacred, но облегчает приемку коммитов, которые выглядят для апстрима проще, чем

1.0 + мои коммиты  -  мердж
    |                 /   \
    - коммиты апстрима     мердж


gds November 22nd, 2012
так просто hg rebase --keep (после этого, догадываюсь, надо перебить букмарку). Если в "форке в гитхабе" будут две похожие ветки "мои коммиты" (для 1.0 и для 2.0) -- не страшно. Если неэстетично, то можно ещё поиграться: посмотреть, как hg bookmarks --delete отображается на git-репку.
По крайней мере, если цель -- просто приготовить пулл-реквест, то схема сработает, если верить моей интуиции.

orlangur_8eyed November 22nd, 2012
А Kiln пробовал? (Он на Mercurial.)

wizzard0 November 22nd, 2012
Пока нет

mykolad November 23rd, 2012
Тут есть еще один момент: в Mercurial все очень плохо с тем, что в SVN называется externals. Если есть зависимости на другие проекты, то уж лучше просто подложить batch файлик, который будет все обновлять до последней версии.
Есть некоторые экстеншены, которые пытаются эту проблему решать, но ничего у них не выходит. Например, на предыдущей работе использовали subrepositories. В результате, имели жуткое шаманство с hgrc файликами и с тем, куда можно было пушать и куда нельзя.

zerkms December 3rd, 2012
Один раз прописал вложенные репозитории и пользуюсь. Никаких шаманств больше не делал.

fi_mihej November 23rd, 2012
Камент мой не добавился в прошлый раз (жожэ упал) - такчто снова накатал:

>> в меркуриал можно успешно засунуть TFS репозиторий с историей весом несколько Gb, и это не вызывает каких-то тормозов вообще. Очень, очень хорошо. Да, не факт что это нормальная ситуация, но легаси есть легаси, его не изменить.

Для примера, я уже который раз запихиваю папочку .svn в один из бранчей - в дополнение к настроенной hgsubversion - для плучения возможности нормально и без гемора работать с SVN-сервером. Это нормальный рабочий момент. И работает несравненно лучше, чем если использовать _только_ hgsubversion.

  • 1
?

Log in

No account? Create an account