у девопсов лишняя точка контроля

лишнее место где может сломаться

лишняя головная боль

в чем профит?

А что обосновывать? Вы не хотите пиздец в репозитории и не хотите доверять пэкэджисту. За все надо чем-то платить.

А что обосновывать? Вы не хотите пиздец в репозитории и не хотите доверять пэкэджисту. За все надо чем-то платить.

Алексей, Нельзя ругаться! [Предупреждений 1/5]

А что обосновывать? Вы не хотите пиздец в репозитории и не хотите доверять пэкэджисту. За все надо чем-то платить.

а чем это вредит репозиторию?

мой босс не понимает термина "п-ц в репозитории"

какую выгоду получит бизнес?

более предсказуемый цикл релизов. Гитхаб любит падать тогда когда тебе не надо. Сейчас к слову намного реже чем 2 года назад

Чем куча говна, которая никогда не будет вами изменяться вредит?

Чем куча говна, которая никогда не будет вами изменяться вредит?

Алексей, Нельзя ругаться! [Предупреждений 2/5]

мой босс не понимает термина "п-ц в репозитории"

ему и не надо.

более предсказуемый цикл релизов. Гитхаб любит падать тогда когда тебе не надо. Сейчас к слову намного реже чем 2 года назад

почему он будет более предсказуемый?

более предсказуемый цикл релизов. Гитхаб любит падать тогда когда тебе не надо. Сейчас к слову намного реже чем 2 года назад

мы не зависим от гитхаба

вы зависите от пакаджгиста

и от гитхаба следовательно

сейчас нет

ну то есть.... если не коммитить вендоры)

вы зависите от пакаджгиста

не, у них весь вендор в репе :)

вот именно

мне он тоже не нравится

но я не могу это "продать"

обосновать не могу

тип почему держать все в packagist не ок?

ой

в репе

почему коммитить вендоры

ну да

да

дада

нууу.... давай по другому

у тебя нет других проблем?)

оно тебе сейчас мешает?

не мешает

ну и хер с ним

забей и пиши тесты лучше

ну за исключением эстетического чувства

эстетика это хорошо но есть риоритеты

и "потому что все будут пальцем показывать"

эстетика это хорошо но есть риоритеты

именно

так почему вендоров не надо коммитить?

я наверняка уверен что там у вас есть места пострашнее

есть есть

ну вот их сначала реши)

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

а вендоры в git это одно из самых незначительных сомнительных решений

это не проблема если не мешает никому

вооот

я за этим и пришел

а кому она все же мешает?

да это побурчать) не слушай людей в интернетах)

почему собственно это плохо?

откуда этот миф?

так почему вендоров не надо коммитить?

Потому, что вендоры - это не изменяемый вами код. Это как хранить бинарники в гите. Можно, но их содержимое на 100% опрелеляется одним маленьким файлом

https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md

Потому, что вендоры - это не изменяемый вами код. Это как хранить бинарники в гите. Можно, но их содержимое на 100% опрелеляется одним маленьким файлом

норм

короч... это просто странно и все

ничего более

это даже не плохо, многие идут на подобные меры

года 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.

ну первые два пункта это одно и тоже

и вообще бессмысленны, учитывая дешевизну харддисков

третий - ну хз

забей чувак

по-моему это неправда вообще

ERROR: S client not available

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

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

и вообще бессмысленны, учитывая дешевизну харддисков

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

вот это хороший аргумент

дифы коммитов

но тут тоже есть решения

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

я и так composer update коммичу отдельно, даже там где не храню вендоров

мы меняем зависимости раз в пару месяцев, не чаще

дифы коммитов

а дифф composer.lock значит нормально, да? )

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

Да, можно устроить себе конфликт на тысячу файлов. Но это тоже решается мерджем только composer.lock и переустановкой всего этого.

а дифф composer.lock значит нормально, да? )

Да. Почему нет?

Да. Почему нет?

ты в него смотришь?

он нечитаемый

ты в него смотришь?

Я даже мерджу его иногда.

прям вручную?

а дифф composer.lock значит нормально, да? )

с одним файлом "решения" удобнее. Ты можешь ему диф отключить)

он нечитаемый

Хз, у меня читаемый. Надо просто знать, что читать, а что потом можно спокойно перезаписать composer update --lock

с одним файлом "решения" удобнее. Ты можешь ему диф отключить)

как и папке vendor

в теории да

потому я и говорю что решения этой проблемы есть

но это больше кастыли

оке

спасибо

в общем вендоры в гите это ок

прям вручную?

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

в общем вендоры в гите это ок

это не ок, это "и тааак сойдет"

конкретно в твоем случае норм

но если начинать проект с нуля - то я бы 10 раз подумал перед этим предложением

вот опять

это ускоряет разработку?

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

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