Mercurial против Git в Facebook

В гугле, по-моему, ещё распостранён подход trunk-based development, и тысячи людей ложат и ложат в монорепу с говном больше говна каждый день, пока ты пытаешься работать над своей маленькой фичей.

Это не имеет отношения к trunk based development, ты сейчас описал абсолютно любую коллективную разработку в абсолютно любом репозитории. trunk based development это про то что они катятся на прод из транка, а не пердолятся со стабилизационными ветками и версионированными релизами.

пейсбук бы вас забанил

Ну он меня и забанил много раз. Как и другие сайты, включая ЛОР (это не первый мой аккаунт и даже этот был в бане уже дважды).

в нашей реальности забанили их

Да нет, в твоей реальности Facebook ещё существует. Просто тебе в него нельзя. Твой господин так распорядился.

Но вернёмся к нашим тараканам: ты описываешь сценарии, когда ты или твои товарищи по команде сами насрали себе в штаны и сами страдают от запаха. Абсолютно любая система контроля версий выдаст тебе конфликты при изменении одних и тех же строк. Или при изменении истории задним числом. Поэтому так делать не надо.

google alumni

Alumni это же выпускник? Теперь так увольняшек из фаангов называют? Выпускниками?

Альма матер их за ногу!

ps: правильно говорить alumnus

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

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

Веток не существует!

В крайнем случае есть reflglog - ну если очень-очень хочется, но непонятно зачем это делать на удалённоц репе. Коммитов может и не видно, но тот же github, емнип, предлагает посмотреть изменения внесённые force push.

Перцы из Facebook написали разрабам гита с предложением ускорить работу собственно гита, но те их послали, предложив место этого распилить монорепу на кусочки. Лицекниговые такой поворот сюжета не оценили, и тут им подвернулся Mercurial, разрабы которого как раз без проблем приняли патчи с улучшением производительности.

Очень похоже на правду. Mercurial во многом идейный наследник Subversion, только распределённый. В Subversion к таким вещам тоже подходили внимательно.

Перцы из Facebook написали разрабам гита с предложением ускорить работу собственно гита, но те их послали, предложив место этого распилить монорепу на кусочки. Лицекниговые такой поворот сюжета не оценили, и тут им подвернулся Mercurial, разрабы которого как раз без проблем приняли патчи с улучшением производительности.

Очень похоже на правду. Mercurial во многом идейный наследник Subversion, только распределённый. В Subversion к таким вещам тоже подходили внимательно.

Нет. Если пройдёшь по ссылке, там написано, что на момент 2012 Git и Mercurial тормозили примерно одинаково. Но в Mercurial без проблем приняли код из мордокниги, а в Git их послали лесом.

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

Я не очень понимаю какой именно воркфлоу ты себе тут нафантазировал. Что тебе в локальный клон неожиданно прилетят чужие изменения? Нет, такого не бывает. Ни в гугле ни где-либо ещё. Ты спокойно работаешь над фичей и никто ни твой локальный чекаут, ни твою ветку, если она публичная, не трогает. Потом спокойно мержишься в транк. От размера репозитория и того сколько коммитов в секунду приходит в этот транк тут ничего вообще не меняется.

Facebook не одобряю, но у гита и правда проблемы.

Не понятно почему они свн не взяли, оно идеально для корпоративных монореп.

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

Git есть у всех, нет лишних проблем для потребителя клонировать репозиторий

Не думаю что facebook одобрит если какой-то его сотрудник захочет клонировать себе их репу.

практически у всех воркфлоу сопряжен с посткоитальными изменениями коммитов

Плохой воркфлоу. Коммит это считай запись в логе деятельности сотрудника, а логи задним числом править нельзя.

Так у них один проект - фейсбук. И много компонентов. Но стабильно работать должен именно фейсбук в целом, а не каждый его компонент по-отдельности. Более того, даже если компонент работает некорректно - это почти не страшно, если проект при этом работает в целом корректно.

Так написал неправильно, значит делаешь ещё один коммит с исправлениями.

Так ты начинал с trunk based development, а оказывается ты про монорепу.

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

Именно так, и никаких проблем это не вызывает.

потому что она завалена их потугами в кодинге, потом попытками это собрать, потом пофиксить баги, потом половину откатить и переписать.

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

Нормалные люди это за пределы локалхоста не выпускают

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

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

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

Для этого ты не синкаешься. Видимо ты опять о чём-то другом, поэтому на шаг назад:

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

«Совершенно другие проекты» и необходимость изменений в них связана с разрабатываемой фичей или нет? Если нет, то ты по прежнему не синкаешь ветку с фичей, а с «совершенно другими проектами» работаешь в другой ветке или другом чекауте. Если да, то уже трудно представить зачем может понадобиться хотеть синкнуть репозиторий частично. Разрабатываешься ты от синхронизированного состояния репозитория, мержить ты будешь тоже в синхронизированное, а франкенштейн где разные части репы взяты из разных ревизий - это состояние которого ни у кого никогда не было, нет и не будет, какой в нём практический смысл? Но и на это есть куча решений - от git co <ревизия> <пути> который притащит части дерева из любого времени до отдельной ветки с черрипикнутыми изменениями.

Это в ветке разработки, или даже в куче разных веток разработки. А в релизную надо мержить уже готовое одним коммитом, как ты любишь.

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

Перцы из мордокниги не осилили сишку и написали свой костыль для меркуриала. А в итоге на репе в 200к файлов статус в гите отрабатывает за такое же время как в меркуриале с костылем мордокниги
https://public-inbox.org/git/531D8ED9.7040305@gmx.net/t/#u

Ну вот некоторые вынуждены селфхостить свой процесс корпоративной разработки, а в нормальных местах дев-ветки хостит тоже компания.

Тут такое дело, компания хостит ровно то что ей нужно. И не хостит она ветки-помойки ровно потому что они никому не нужны. Код ревьюят полноценными коммитами, blame смотрят по полноценным коммитам, бисектят по полноценным коммитам и черрипикают полноценными коммитами. Никогда этого не делают с мёртвым кодом, десятками коммитов с месседжем «fix» и не собирающимися коммитами сделанными потому что рабочий день закончился. Полноценные коммиты, напомню, это ни в коем разе не squash, а набор небольших атомарных изменений получившихся в результате причёсывания фичабранча перед мержом.

Кстати, совсем забыл, недавно было неплохое выступление в том числе про фичи git для больших реп, оно обязано быть в этой теме:

https://www.youtube.com/watch?v=aolI_Rz0ZqY

но те их послали, предложив место этого распилить монорепу на кусочки.

Они правильно сделали. Монорепа это антипаттерн, который применяется от бессилия и лени.

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

И что это за патчи? Которые позволяют подменять backend так, чтобы от mercurial оставалась только система команд и которые превращают dvcs в vcs?

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

Ветки это антипаттерн. Долгоиграющих веток быть не должно вообще. Ветка здорового человека живет 1 максимум 2 дня, после чего вливается в мастер и удаляется. А если параллельно не работаешь над разнородными изменениями, то можно жить только в своем личном мастере без веток, периодически ребейзя его на remote master.

git-merge не просто так изобрели.

Он замусоривает историю. Нормальные люди таким не пользуются. А изобрели его только потому что авторы гита тогда не знали как делать правильно.

потому что бывают и циклические зависимости и вообще всё зависит от всего.

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

чтобы понять исходный замысел автора строчки кода например

Для этого надо коммит-мессаджи нормально писать.

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

С такими вообще лучше не работать.

Бранч также может потребоваться чтобы восстановить окружение к определенной версии

Если у вас не работает просто чекаут на определенную ревизию и надо еще дополнительно с бубном танцевать для «восстановления окружения», то надо выпрямлять руки.

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

Прекрати демагогию. Ты хотел коммит, соответствующий осмысленной релизной правке - вот я тебе написал как они делаются. И он при этом вполне независимый и атомарный. Что за «сквош» я не знаю.

авторы гита тогда не знали как делать правильно

Они и сейчас не знают.

Если продолжить твою логику, то хостить коммиты вообще не нужно. Разраб принёс свой патч - проверили, внесли в рабочий (релизный) код, забыли. Конечно нет, надо помнить кто что когда делал. И не только релизные коммиты, но и процесс разработки - это то же самое, но с повышенной детализацией.

Это нужно и самому разработчику: можно через год будет вспомнить, зачем он внёс в код какую-то мелочь, в релизном коммите пришедшую уже как часть целого, а вот в детальном логе будет видно после чего, для фикса чего её дописали, а может даже и с комментарием в коммит-логе. Или почему отвергнут один из двух вариантов реализации чего-то - в коммитах могут быть видны попытки привести неудавшийся алгоритм в работоспособное состояние и наглядная демонстрация того, почему его не надо делать.

И компании:

1) если разработчик уйдёт, то все его наработки автоматически остаются в централизованном месте, куда просто даётся доступ продолжателю этой разработки,

2) можно примерно оценить эффективность использования рабочего времени, у разработчика нет варианта «делаю всё на локалхосте, поэтому вам ничё не видно» с сокрытием реального процесса от руководства.

обеспечить согласованность контрактов > 1000 единиц это ведь сущие пустяки

но звучит, что проблема архитектурная. Не может человеческое существо собрать в голове 1000 раздельных библиотек.

он тебя обманул. Искать по словам google piper и google fig. Например https://mercurial.paris/download/Mercurial%20at%20Google.pdf

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

Отправляй коммиты пачкой. Зачем отправлять их не доделав работу?

сейчас практически любой проект на языке с динамической типизацией невозможно собрать через пару лет после выпуска

Не думаю, что тут проблема связана с динамической типизацией. Всякие ноды лочат версии зависимостей. Проблемы как раз в том, что существуют проекты с 1000 зависимостей, что противоестественно и плохо.

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

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

джуны подсидят

ну или тебя прет работать в таком месте, где код живет неделю (из таких мест не любят уходить, там очень драйвово), или просто иди работать туда, где ценят тех, кто удерживает проект от сползания в хаос.

Коммиты, конечно, редактировать нужно, но не в мастере, а в ветке. Чтобы каждый коммит был осмысленным, изолированным, мотивированным.

точно не хуже дублирующих реализаций

это самый тонкий тезис не всегда выдерживающий проверку практикой.

Я пока всё ещё не понимаю: если фича тестируется в отдельной ветке, допустим, что туда даже подтягиваются изменения из основной, то зачем лезть править свои старые коммиты, если поверх них уже лежат коммиты друг х людей? Пусть даже так, почему бы это в конце не сделать, договорившись с другими перед merge?

присылают порции с десятками правок в вордовском документе

А рукописи не присылают сделанные от руки на листе бумаги?

ну или тебя прет работать в таком месте, где код живет неделю

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

Чтобы каждый коммит был осмысленным, изолированным, мотивированным.

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

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

2. обновление требуется для установления совместимости с апстримом, ведь только совместимый код может попасть в основную(или специальную) ветку

допустим, что туда даже подтягиваются изменения из основной

Это всё делается до мёрджа в мастер.

1. Не пиши коммиты в неадекватном состоянии, с большой долей вероятности изменения при этом тоже были сделаны в неадеквате.

Что это за коммиты?

вы немного друг-дружку читайте тоже:) одни пишут: «дурак, делай коммиты цельными и осознанными», другие тут же: «дурак, коммить как легло, потом еще, Аллах разберет»

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

зачем лезть править свои старые коммиты, если поверх них уже лежат коммиты друг х людей?

очень хороший вопрос.

При trunk based development нормальная практика редактировать свои коммиты. Но это работает, если в ветку фигачишь один.

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

У меня стандартная практика — ребейз от мастера перед мержем, организация изолированных коммитов и коммит с обязательным merge commit, чтобы было видно: вот Вася влил свои изменения и вот после них тут хрустнуло.