LINUX.ORG.RU

Mercurial против Git в Facebook

 , ,


0

5

Привет, ЛОР!

Нашёл довольно интересную заметку о том, почему некоторые до сих пор используют Mercurial. В частности, Facebook этим славен. Может кому интересно тут будет.

https://graphite.dev/blog/why-facebook-doesnt-use-git

TL;DR для Ъ:

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

С тех пор в мордокниге царствует Mercurial.

жирная монорепа

Это ты ещё Google не видел. В ихней монорепе всё, совсем всё. Она такая большая, что ещё только по частям через подобие fuse монтируют. И да, там Git.

beastie ★★★★★
()

Mercurial

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

IIIypuk ★★★★
()
Ответ на: комментарий от beastie

Это ты ещё Google не видел. В ихней монорепе всё, совсем всё.

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

Но да, я не удивлён, учитывая что гугель те ещё говноделы. Крупная контора из чего угодно сделает ClearCase.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от IIIypuk

Да нет, ты просто привык к git. Тут некоторые так же до сих пор ноют, что мол git на svn не похож.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от grem

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

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от grem

«Это что же вместо svn checkout запускать git clone? Вместо svn update - git pull? Ни за что!»

Про работу с сабмодулями пошути теперь.

thesis ★★★★★
()
Ответ на: комментарий от hateyoufeel

Зачем держать монорепу с говном? Тут вон про модули подсказывают, в svn они проектами тоже используются успешно.

grem ★★★★★
()

В частности, Facebook этим славен

Нет, Фейсбук славен тем, что это абсолютный мировой лидер говноделия, недосягаемый в этом, как звезда Эарендел.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от grem

Зачем держать монорепу с говном?

Потому что это проще, чем синхронизировать десяток различных репозитариев друг с другом. Хотя подход и не лишён недостатков, конечно же.

Тут вон про модули подсказывают, в svn они проектами тоже используются успешно.

Сабмодули в гите – это просто сраный ад. Геморроя с ними полная жопа.

hateyoufeel ★★★★★
() автор топика

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

Syncro ★★★★★
()
Ответ на: комментарий от Syncro

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

Признайся, ты еду через жопу ешь?

Гит постоянно лепит конфликты и неожиданности там где их могло ге быть, из-за переносов строк например,

Вау! Файл поменялся, система контроля версий тебе об этом сказала. Как же так?

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

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Признайся, ты еду через жопу ешь?

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

Вау! Файл поменялся, система контроля версий тебе об этом сказала

надо чтобы проверяла и предупреждала, а не обдристывала все

Syncro ★★★★★
()
Ответ на: комментарий от Syncro

А если ещё и строчки местами менять в файлах из коммитов при ребейзе….

grem ★★★★★
()
Ответ на: комментарий от alysnix

но там кажется меньше возникает потребности в грязных хаках

Syncro ★★★★★
()
Ответ на: комментарий от Syncro

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

Нет, не сопряжён. Так делают только говноделы.

hateyoufeel ★★★★★
() автор топика

Разве не логично использовать для разных проектов разные репы? Скажем, имеем мы два проекта, которые делают совершенно разные вещи, никак не связаны. Зачем их в одну репу пихать? Очень странно решение, нет?

MoldAndLimeHoney
()
Ответ на: комментарий от MoldAndLimeHoney

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

Syncro ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

Syncro ★★★★★
()
Ответ на: комментарий от Syncro

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

Нет, нормальные люди просто без проблем делают правки отдельным коммитом. А потом делают squash при мерже и туда уже пишут нормальные комментарии.

Блин, я тут вспомнил твои рассказы про анал-карнавал с gitlab. Меня теперь совсем не удивляет, что ты тут про чрезжопный метод разработки рассказываешь. Госконтора, да?

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от grem

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

Syncro ★★★★★
()
Ответ на: комментарий от beastie

Это ты ещё Google не видел. В ихней монорепе всё, совсем всё. Она такая большая, что ещё только по частям через подобие fuse монтируют. И да, там Git.

У гугла же был уродец perforce, свалили с него? В яндексе тоже монорепа монтируется через fuse.

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

anonymous
()

Лицекниговые

в мемориз

2012
была жирная монорепа

уже 12 лет прошло, гит уже торт, емнип

etwrq ★★★★★
()
Ответ на: комментарий от hateyoufeel

Нет, нормальные люди просто без проблем делают правки отдельным коммитом. А потом делают squash при мерже и туда уже пишут нормальные комментарии.

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

Syncro ★★★★★
()
Ответ на: комментарий от Syncro

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

Что ты несёшь, болезный?

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

Нет, это все так работают. За git push --force без особо важных на то причин получают линейкой по пальцам. Любое изменение – отдельный новый коммит, вот и всё.

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

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Да нет, ты просто привык к git.

У меня тут релевантный опыт - я пытался начать именно с mercurial. Проходил и «удалить репу и склонировать заново», не мог разобраться как избавиться от multihead состояния и совсем прифигел когда оказалось что ветку нелья удалить. Переполз на git и никаких проблем больше не знал.

Так что нет никаких «привык», hg - это действительно неудобнейший инструмент.

anonymous
()

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

anonymous
()
Ответ на: комментарий от hateyoufeel

Блин, я тут вспомнил твои рассказы про анал-карнавал с gitlab.

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

Syncro ★★★★★
()
Ответ на: комментарий от anonymous

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

Syncro ★★★★★
()
Ответ на: комментарий от Syncro

любое изменение - конфликт

Так не надо над одной веткой одновременно впятером работать, болван. git-merge не просто так изобрели.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Сабмодули в гите – это просто сраный ад. Геморроя с ними полная жопа.

Геморроя с ними вообще никакого нет - в использовании ничем не отличаются от современных языкоспецифичных пакетных менеджеров. В cargo (pip, yarn, где угодно) ты добавил зависимость, её версия залочена, с ней собираешься и никаких неожиданностей никогда не поимеешь. А захотел - обновишься одной командой. Вот с сабмодулями абсолютно то же самое. Одной командой можно переключиться на любой коммит, тэг, или вообще другой репозиторий. А когда в качестве сабмодуля свой (r/w) репозиторий можно прозрачно разрабатывать его вместе с внешним проектом.

Но для корпоративных монореп это никак не помогает, потому что монорепа это не дерево из модулей, и зачастую даже не DAG, потому что бывают и циклические зависимости и вообще всё зависит от всего. Это принципиально невозможно побить на модули, и работать с этим можно только особыми VCS (умеющими селективный чекаут по прописанным зависимостям (как у гугла было в их обёртке над перфорсом), либо динамическую подгрузку контента через fuse (как наверное сейчас сделано)) и особыми системами сборки (в яндексе, например cmake в своё время также перестал справляться).

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

anonymous
()
Ответ на: комментарий от hateyoufeel

Так не надо над одной веткой одновременно впятером работать

с одной веткой как раз порешать может быть проще(стешом и ребейзом), но так и правда сейчас редко работают

Syncro ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

anonymous
()
Ответ на: комментарий от hateyoufeel

Сабмодули в гите – это просто сраный ад. Геморроя с ними полная жопа.

Если сабмодули не абюзить, то это вполне рабочий инструмент. Геморой с ними только если хеши сабреп часто двигаются, это точка конфликта.

PRN
()
Ответ на: комментарий от Syncro

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

Давай-ка пример зачем тебе может понадобиться восстановить ветку и с чем-то её сравнить, я с таким за 25 лет в бигтехе и СПО не сталкивался. Есть история коммитов, кроме неё ничего не нужно.

anonymous
()
Ответ на: комментарий от anonymous

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

Syncro ★★★★★
()
Ответ на: комментарий от anonymous

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

Дык а я о чём. В итоге, на сервер ничего из этого говна не уходит, все фиксы остаются локальными, а значит коммент @Syncro про то, что результат git commit –amend не складывается с git merge идёт мимо.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от Syncro

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

Для этого достаточно коммита.

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

Для этого достаточно коммита.

anonymous
()
Ответ на: комментарий от hateyoufeel

Дык а я о чём. В итоге, на сервер ничего из этого говна не уходит, все фиксы остаются локальными, а значит коммент @Syncro про то, что результат git commit –amend не складывается с git merge идёт мимо.

Я думал он про то что если ты изменил PR после отправки (но до мержа) и сделал force push, то коммитов старой версии не видно. Ну так туда им и дорога.

anonymous
()
Ответ на: комментарий от anonymous

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

Syncro ★★★★★
()
Ответ на: комментарий от hateyoufeel

если коммит уехал в другие бранчи(например на тестинг-стеиджинг) изменять его будет опасно: минимум конфликты будут

Syncro ★★★★★
()
Ответ на: комментарий от Syncro

если коммит уехал в другие бранчи(например на тестинг-стеиджинг) изменять его будет опасно: минимум конфликты будут

Слушай, у меня для тебя совет: раз не можешь нормально срать, не мучай жопу. Всё это явно не твоё.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

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

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

rupert ★★★★★
()
Ответ на: комментарий от Syncro

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

Что это вообще нахрен значит и на какой пункт это ответ? Если на второй, то код всегда был собран из конкретного коммита, значит чтобы «восстановить окружение» вам нужен этот конкретный коммит.

anonymous
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.