Я разобрал отдельный кейс, где монорепа неудобна. Ты только написал про то, что Борис просто ленивый, ничего не написав, почему это плохо. Конкретно этот способ иногда позволяет закрыть проблему куда быстрее.

Разве? В случае с монорепой - ты сделал клон и запускаешь бранч Бориса отдельно как и с мультирепой без ребейзов. А вот сделать мёрдж мультиизменений трансакционный с мультирепой не сделаешь.

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

Твоя транзакционность изменений условна.

Вполне объективна, если изменение затрагивает с 5-ок репозиториев - нужно синхронизировать это. Это не условность, а объективная необходимость синхронизации, которой в мультирепе нет.

Просто как операция отдельно от контекста она нисколько не крайняя.

Почему она не крайняя? Амендить локальный коммит — окей. Тут моно/мульти репы вообще ни при чём. Амендить ремоут коммит — это значит переписывать историю, которой ты уже поделился, на которую кто-то может уже рассчитывать (даже если кто-то пулльнул и просто читает код, а особенно, если кто-то от тебя отбранчевался). Самое главное, я не понимаю зачем амендить хотфиксы. Если получается большой размер репы, то гит умеет это сжимать. Если смущает что история портится, то сквошьте при мердже

Мне лень повторять то, что я уже написал.

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

По работающему приложению - вот именно. Если у тебя стабильный мастер, то любой коммит из мастера мультирепы даст тебе рабочнее приложение. В случае же мульти реп - чтобы получить рабочее приложение - нужна синхронизация кучи репозиторий и бранчей. И понимание, какая feature в приложении X нужна, чтобы фича в приложении Y запустилась и приложение Z не сломалось.

По работающему приложению - вот именно. Если у тебя стабильный мастер, то любой коммит из мастера мультирепы даст тебе рабочнее приложение. В случае же мульти реп - чтобы получить рабочее приложение - нужна синхронизация кучи репозиторий и бранчей. И понимание, какая feature в приложении X нужна, чтобы фича в приложении Y запустилась и приложение Z не сломалось.

Так ты проверяешь, что все мастеры норм работают, и всё. В чём отличие?

Так ты проверяешь, что все мастеры норм работают, и всё. В чём отличие?

Так ты проверяешь, что все мастеры норм работают, и всё. В чём отличие?

Так ты проверяешь, что все мастеры норм работают, и всё. В чём отличие?

В том, что когда тебе нужно сделать изменение в 5 репозиториев. Ты допустил - замёрджил ветку в мастер в репозитории X, а в Y идёт ещё ревью.

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

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

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

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

у меня на новой работе нужно все амендить и придерживаться 1 задача = 1 коммит

у меня на новой работе нужно все амендить и придерживаться 1 задача = 1 коммит

Ну, в одной компании я зафорсил squash and merge для PR-ов, потому что разработчики создавали десятки коммитов типа fixed typo, add test, fix line каждый день и история за месяц уже была такой, что там не разобраться. Только сообщение в merge commit-е имело хоть какой-то смысл. Скажем так, где культура коммитов когда-то изначально была убитая - такой кардинальный подход - возможно единственно действенный.

Ну, в одной компании я зафорсил squash and merge для PR-ов, потому что разработчики создавали десятки коммитов типа fixed typo, add test, fix line каждый день и история за месяц уже была такой, что там не разобраться. Только сообщение в merge commit-е имело хоть какой-то смысл. Скажем так, где культура коммитов когда-то изначально была убитая - такой кардинальный подход - возможно единственно действенный.

Всем читать Канемана

Зачем?

Snake

У меня ещё рабочий день...

Например что не совсем хуйня?

Например что не совсем хуйня?

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

Задачи одинаковые решают

Я получаю деньги за то что пишу то, что какой-то чувак уже написал, но копирайт не даёт это взять

Ага все давно поняли нормально делай нормально будет

Я б зависимость популярности и хуиности вообще не проставлял

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

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

Не, всё популярное — хуйня по определению. Популярное = нравится большинству А большинство это самая тупая масса, которая может быть. И тут дело не в том что большинство людей тупые (я не считаю что большинство людей тупые), а в том, что чем больше масса людей, тем она менее сознательная и более инертная.

у тебя есть абсолютный трешхолд после которой нечто становится хуйнёй