Про умолчания (github)

Всё-таки неадекват Git'a пролазит и в Github. Совсем чуть-чуть, там всё-таки офигенно крутые чуваки сидят, но всё равно пролазит.

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

Оказывается, их там нет о_О. Ну то есть Watch Changes позволяет подписаться на Issues, а на коммиты надо подписываться в Services and Webhooks.

И это еще полбеды, но для чужих репозиториев подписаться вообще нельзя :/

Ну кто так делает, блин...

Почему 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 проект" (централизованный).

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

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