🐴
мой босс не понимает термина "п-ц в репозитории"
Sergey
какую выгоду получит бизнес?
более предсказуемый цикл релизов. Гитхаб любит падать тогда когда тебе не надо. Сейчас к слову намного реже чем 2 года назад
Alexey
Чем куча говна, которая никогда не будет вами изменяться вредит?
Чем куча говна, которая никогда не будет вами изменяться вредит?
Алексей, Нельзя ругаться! [Предупреждений 2/5]
🐴
более предсказуемый цикл релизов. Гитхаб любит падать тогда когда тебе не надо. Сейчас к слову намного реже чем 2 года назад
почему он будет более предсказуемый?
🐴
Sergey
вы зависите от пакаджгиста
Sergey
и от гитхаба следовательно
🐴
сейчас нет
Sergey
ну то есть.... если не коммитить вендоры)
🐴
вот именно
🐴
мне он тоже не нравится
🐴
но я не могу это "продать"
🐴
обосновать не могу
Sergey
тип почему держать все в packagist не ок?
Sergey
ой
🐴
в репе
Sergey
почему коммитить вендоры
Sergey
ну да
🐴
да
🐴
дада
Sergey
нууу.... давай по другому
Sergey
у тебя нет других проблем?)
Sergey
оно тебе сейчас мешает?
🐴
не мешает
Sergey
ну и хер с ним
Sergey
забей и пиши тесты лучше
🐴
ну за исключением эстетического чувства
Sergey
эстетика это хорошо но есть риоритеты
🐴
и "потому что все будут пальцем показывать"
🐴
так почему вендоров не надо коммитить?
Sergey
я наверняка уверен что там у вас есть места пострашнее
🐴
есть есть
Sergey
ну вот их сначала реши)
🐴
получается, что вендоры в репе это выдуманная проблема
Sergey
а вендоры в git это одно из самых незначительных сомнительных решений
Sergey
это не проблема если не мешает никому
🐴
вооот
🐴
я за этим и пришел
🐴
а кому она все же мешает?
Sergey
да это побурчать) не слушай людей в интернетах)
🐴
почему собственно это плохо?
🐴
откуда этот миф?
Alexey
так почему вендоров не надо коммитить?
Потому, что вендоры - это не изменяемый вами код. Это как хранить бинарники в гите. Можно, но их содержимое на 100% опрелеляется одним маленьким файлом
Ivan
https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md
Sergey
короч... это просто странно и все
Sergey
ничего более
Sergey
это даже не плохо, многие идут на подобные меры
Sergey
года 3-4 назад мы тож коммитили вендоры потому что дебилы на гитхабе любили переименовывать/удалять репозитории и зависимости ломались
🐴
Large VCS repository size and diffs when you update code.
Duplication of the history of all your dependencies in your own VCS.
Adding dependencies installed via git to a git repo will show them as submodules. This is problematic because they are not real submodules, and you will run into issues.
🐴
ну первые два пункта это одно и тоже
🐴
и вообще бессмысленны, учитывая дешевизну харддисков
🐴
третий - ну хз
Sergey
забей чувак
🐴
по-моему это неправда вообще
🐴
у меня есть либы из гита напрямую, никаких там сабмодулей
Sergey
проблемы будут возникать только если часто меняешь версии зависимостей в контексте брэнчей
Alexey
и вообще бессмысленны, учитывая дешевизну харддисков
Вопрос не в дисках, а в том, что твои коммиты, где ты обновил зависимости будут эпичными простынями.
От этого можно спасаться коммитя зависимости отдельно от бизнес-логики.
Sergey
вот это хороший аргумент
Sergey
дифы коммитов
Sergey
но тут тоже есть решения
🐴
Вопрос не в дисках, а в том, что твои коммиты, где ты обновил зависимости будут эпичными простынями.
От этого можно спасаться коммитя зависимости отдельно от бизнес-логики.
я и так composer update коммичу отдельно, даже там где не храню вендоров
🐴
мы меняем зависимости раз в пару месяцев, не чаще
Alexey
проблемы будут возникать только если часто меняешь версии зависимостей в контексте брэнчей
Да, можно устроить себе конфликт на тысячу файлов. Но это тоже решается мерджем только composer.lock и переустановкой всего этого.
🐴
он нечитаемый
🐴
прям вручную?
Sergey
а дифф composer.lock значит нормально, да? )
с одним файлом "решения" удобнее. Ты можешь ему диф отключить)
Alexey
он нечитаемый
Хз, у меня читаемый. Надо просто знать, что читать, а что потом можно спокойно перезаписать composer update --lock
Sergey
в теории да
Sergey
потому я и говорю что решения этой проблемы есть