Previous Entry Share Next Entry
2016-01

Почему release process у Git'a - говно, а Mercurial в 100 раз круче

Я давно уже обещал написать, чем Mercurial лучше Git, и наконец-то часть написал.
Продолжая дискуссию об отсутствии commit notification на Гитхабе:

sorcerer_
> Дык пул реквесты - это ишуи и есть.

Тут два нюанса:
1. Я хочу вотчить чужие репозы. Когда туда коммитит один человек - никаких PR он не делает. А когда коммитят многие - то тоже могут не делать, и убедить их изменить их воркфлоу — занятие безнадёжное, да и вообще, кхм, зачем лезть в чужой огород-то.

2. Для PR в свои репозитории: это работает, если процесс разработки централизован, девелоперы сидят в форках, а релизер - на апстриме. Это вполне понятный flow для больших проектов, где есть Core Team и контрибьюторы, но он мне не нравится, т.к.

а) нарушает идею DVCS в плане равенства контрибьюторов
б) подразумевает, что релизеров 1-2, а контрибьюторов куча. Если для корп кастомеров надо поддерживать разные веточки, то типична ситуация когда 4 человека релизят скажем 10 веток, и что тогда? что такое PR? делать 10 апстрим репозиториев и пушать M*N пул реквестов? по-моему, это абсурд.
в) аналогично, очень раздражают попытки гита отслеживать состояния апстримов, перевешивая теги (xxxxx/master и т.д.), т.к. это делает fetch не-идемпотентной операцией.

А понадобился этот костыль им вот почему:

sorcerer_
> за коммиты без пул реквестов - азаза!!

Кто ж в мастер коммитит-то? Коммитить надо в личную feature branch коммиттера, которую потом соответствующий релизер мержит в нужные release branch-и.

Ахнуда, умолчания в Git, когда предполагается rebase'ить коммиты поверх ориджина без создания явной точки мержа, собственно говоря, и провоцируют коммитить в мастер и делать точки мержей неявными. А еще это позволяет сделать orphaned коммиты и вообще по-разному изгавнять репоз, чего не может случиться в Mercurial, т.к. history is sacred.

Известный концепт "все операции в Git выражаются через rebase" - это неправильно.

Я бы даже сделал еще чуть радикальнее, чем в Mercurial сейчас, и по умолчанию при первом коммите, или коммите поверх чужого бранча требовал создавать feature бранч. Это бы позволило
а) seamlessly эволюционировать личный проект в shared
б) решило проблему "люди коммитят в мастер и разводят там гавнище"

Совокупно, релиз-процесс Mercurial, когда все форки равноправны и лейблы веток после того, как все сделали push/fetch, совпадают у всех девелоперов - существенно снижает когнитивную нагрузку и упрощает мержи/релизы. А релиз-процесс Git'a оставляет неприятный осадочек SVN/TFS, и позволяет превратить в месиво как свой репоз, так и апстрим, после чего разбираться по мэйлу/телефону "где чего зафакапилось и как исправлять" - намного сложнее.

Т.е. умолчания в Mercurial покрывают кейсы "личный проект", "b2b проект" (для корп клиентов) "bazaar проект" (децентрализованный, без явного владельца), а умолчания в Git покрывают сугубо "b2c проект" (централизованный).

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

Давайте обсудим, что ли.

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

  • 1
__ronin__ December 18th, 2014
Пока вижу основную мысль только на тему умолчаний. Это, конечно, важно, но на мой взгляд, это таки не showstopper.
Вторая мысль - речь все таки о Github, а не о гите как таковом. По моему в гите есть все необходимые хуки, чтобы реализовать желаемое поведение. Другой вопрос что github решил сделать по-своему, и в причинах надо разбираться отдельно.
Третий момент - пропоненты меркуриала любят указывать на различия веток как сущностей, в git и mercurial. Здесь, мне кажется вопрос складывается из двух - во-первых, не в последнюю очередь возможности инструмента часто провоцируют поиск применения для них, равно как и наоборот, а во-вторых никто не отменял вопрос личных предпочтений - "мне нравится возможность X, в M его нету, следовательно M говно".
Disclaimer: Использовал и то и другое, к меркуриалу так и не смог притереться, в том числе, пару раз доконала его тормознутость. С workflow гита проблем пока не встречал, что в общем-то подтверждает мой крайний пойнт чуть выше.
Как-то так.

wizzard0 December 18th, 2014
> пару раз доконала его тормознутость

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

Но более приземленных 150 гб и пару миллионов файлов туда запросто ложится, и не вызывает OutOfMemory, в отличие от Git'a.

Кучи коммитов и мержей тоже, в целом, нормально.

Когда тормозит-то, короче?

> хуки

Проблема хуков в том, что это код. Который не то чтобы очень приятно мейнтейнить, когда часть народу сидит на винде, часть на линуксе, часть на макоси. И гит у них то из SourceTree, то от Github'a, то из Cygwin'a, то ли еще какой.

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

> С workflow гита проблем пока не встречал

Ну они сводятся к "у людей репозы уходят в сильный рассинхрон", но вообще гораздо больше задалбывают out of memory и просто ситуации когда корраптится репоз (гитхаб начинает выдавать error 500 и всё такое). Когда коммиттер может необратимо похерить апстрим - это вполне себе шоустоппер, имхо.

Может, это просто баги - но извините, это система контроля версий или что?

Edited at 2014-12-18 10:10 am (UTC)

p1r4nh4 December 18th, 2014
> Ахнуда, умолчания в Git, когда предполагается rebase'ить коммиты поверх ориджина без создания явной точки мержа,

Гмм... Не понял. Таких умолчаний нет. Ребейз он делает только если ты попросишь.

Я хг люблю больше, но задолбался с тем, что везде гит, а я хочу хг, и в конце концов плюнул и тож юзаю гит. Иногда нужно git merge --no-ff делать, но в меркуриале в таком случае тоже надо танцевать, по дефолту он так же себя поведëт, как и гит.

wizzard0 December 18th, 2014
> Гмм... Не понял. Таких умолчаний нет.
> Иногда нужно git merge --no-ff делать

Не иногда, а всегда, вот я о чем.

> но задолбался с тем, что везде гит, а я хочу хг

Я пересадил на меркуриал уже три конторы :)

Edited at 2014-12-18 10:25 am (UTC)

sassa_nf December 18th, 2014
а есть меркуриалхаб?

mbr December 18th, 2014
Хороший, плохой - главное где больше разработчиков. Где-то там недавно народ соскакивал с mercurial из-за того, что большинство юзает гит.

wizzard0 December 18th, 2014
Это печалька. Но ничо, настанет праздник и на нашей улице. Когда-то все на CVS сидели, и ничо)

avnik December 18th, 2014
У меня ощущение, что вы коллега решаете (пытаетесь решить) организационную проблему техническими средствами.

Если взять за правило вливать фичебранчи _только_ с --no-ff то и каши в мастере не будет.
Делать фичебранчи в своем клоне на гитхабе, или в общем репо -- это опять же вопрос policy принятого в команде.
(тот же git flow например рекомендует --no-ff)

wizzard0 December 18th, 2014
> Если взять за правило вливать фичебранчи _только_ с --no-ff то и каши в мастере не будет.

Логично. Я об этом и говорю. Меркуриал так делает по дефолту.

> организационную проблему техническими средствами.

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

sorcerer_ December 18th, 2014
Не понял ничего из написанного. :)
Поэтому буду про ключевые слова.
Идея равенства коммитеров - говно идея.
Никто никому не равен, т.к. релизер должен быть диктатором, а не демократией.
Гит придумывался для кернеля, там флоу вообще другой: патчи мылом, кстати так тоже ок работает, проверено.
Гитхаб, как и любой СааС - хуета полная, но это общая для всех СааС-ов проблема.

wizzard0 December 18th, 2014
> Идея равенства коммитеров - говно идея.
Никто никому не равен, т.к. релизер должен быть диктатором, а не демократией.

Это если у нас, грубо говоря, юзеры ставят пакеты только из репо пакетов.
Тогда релизер диктатор, да.

А если у нас тусовка мейнтейнеров из разных дистрибов, которые из чувства доброй воли сабмитят друг другу патчи под MIT - то никто никому ничего не должен.

> Гит придумывался для кернеля
С этим я не спорю. И там резонно что релизер диктатор btw

> Гитхаб, как и любой СааС - хуета полная, но это общая для всех СааС-ов проблема.
Оооок :)

4da December 18th, 2014
> нарушает идею DVCS в плане равенства контрибьюторов
странная идея какая-то

wizzard0 December 18th, 2014
Ну это штука субьективная, бесспорно :-)

max630 December 18th, 2014
> аналогично, очень раздражают попытки гита отслеживать состояния апстримов, перевешивая теги (xxxxx/master и т.д.), т.к. это делает fetch не-идемпотентной операцией

не понял. Теги гит не перевешивает (в норме теги все-таки не меняются), он меняет remote ссылки, естественно если они поменялись между фетчами. И fetch идемпотентный, ну пока аптрим не поменялся конечно.

> Ахнуда, умолчания в Git, когда предполагается rebase'ить коммиты поверх ориджина без создания явной точки мержа

ничего такого в гите нет по умолчанию. Скорее наоборот, workflow самого гита (на kernel не смотрел) довольно неудобен именно с гитом из-за того что надо ребейзить постоянно. Я сейчас пробую проект без ребейзов в feature бранчах совсем - нормально всё.

max630 December 18th, 2014
а при мерже пуллреквеста разве не делается --no-ff? я с гитхабом не пробовал но в аналогах делается.

max630 December 18th, 2014
> делать 10 апстрим репозиториев и пушать M*N пул реквестов? по-моему, это абсурд

апстрим веток. разве он не даёт выбирать ветку в которую мержить?
большое число пулреквестов да. ну сколько мержей - столько и пулреквестов. Опять же не вижу как иначе можно было бы сделать.

tretiy3 December 18th, 2014
просто ты пишешь про гитхаб, а не про гит.
тебя выдают сразу "чужие репозы". что это такое, вообще? и зачем их вотчить?

wizzard0 December 19th, 2014
гмм, чтобы понимать, что происходит в интересных мне проектах? )

max630 December 19th, 2014
вообще гитхаб конечно не торт, мне гиториус больше нравился. сразу видно разницу между опенсорсом и закрытыми поделками :)

  • 1
?

Log in

No account? Create an account