Создание оружия для социалистического государства это почетно по тому, что соц. государства не нападали, а сдерживали кап. страны от развязывания войн. Теперь, когда Россия стала капиталистической страной и ни чем не отличается от остальных, естественно, вам пришлось задуматься об этике.
А вот тут ошибка. В 90-е годы пацаны четко разделяли сферы и людей. Если вы придете на разборку и заявите, что вы "работник", с вами ни кто и разговаривать не будет по тому, что работники не при делах. Их конечно можно «разводить», но только на этапе заключения соглашения, а выставлять себя дебилом перед работниками — это вообще западло!
Именно, онлайн заявление в прокуратуру (+ письма чиновникам и репортерам) и, что самое главное, заявление надо составлять и адресовать так, чтобы не просто заявить, а по возможности натравить друг на друга «сильных» и враждующих конкурентов, засевших в различных ветвях власти (всем нужны поводы). Если наверху найдется заинтересованная сила, то все пойдет как по маслу. Ну а если нет, то и до суда дело никогда не дойдет.
git-subrepo и git-subtree не отменяет возможность ведения upstream-репозиториев как самостоятельных продуктов, а в основном дереве держать либо squashed-комиты, либо полноценные истории.
А на счет папочек в .gitignore все зависит от CM инженера. Либо он настраивает права пользователей и хуки, либо он отдает все на откуп инженерам команды разработчиков.
Представим, например, следующую задачу. Ваш проект состоит из нескольких подпроектов/модулей и, допустим, один модуль представляет исходный код межмодульных интерфейсов. Набор интерфейсов, разрабатываемый отдельной командой, должен быть фиксирован для каждой ветки вашего проекта. Более того, никто из других команд разработчиков не должен иметь права изменять код интерфейсов, а наоборот, совершенствовать свой модуль в строгой согласованности с другими.
В этом случае CM инженер решит поставлять в каждую ветку проекта конкретные, фиксированыые ревизии интерфейсного модуля и постарается запретить любые комиты со стороны разработчиков. Только при переходе на новую версию интерфейсного модуля, все остальные команды создадут новые ветки собственных модулей, подключат к ним новую версию интерфейсного модуля и начнут работать над собственным кодом с целью приведения его в соответствие новой версии интерфейсов.
Согласитесь, что при данном подходе интерфейсный модуль лучше всего подключать не как submodule, обвязывая его хуками, а как subtree (а вот нужна ли при этом история интерфейсного модуля в общем индексе, это уже другой вопрос).
Дело не в преимуществе, а в целесообразности. Главное отличие состоит в том, что при использовании submodules, пользователь снимает репозиторий-контейнер практически не настроенным и ему надо проделывать дополнительные мероприятия по согласованию ревизий подмодулей и репозитория-контейнера (так или иначе, это именно так, и автор проекта должен обеспечить пользователя соответствующими инструкциями, будь то простая инструкция по клонированию `git clone --recurse-submodules ...' или другое напоминание). Если же мы говорим о git-subrepo и git-subtree, то здесь, копируя репозиторий-контейнер, пользователь получает полностью настроенное дерево за одну операцию git-clone(1). Все для него уже сделано автором. А в остальном, все зависит от задач, которые решает автор и от его политики SCM (Source Configuration Management).
Создание оружия для социалистического государства это почетно по тому, что соц. государства не нападали, а сдерживали кап. страны от развязывания войн. Теперь, когда Россия стала капиталистической страной и ни чем не отличается от остальных, естественно, вам пришлось задуматься об этике.
Разумеется ccache не замена. Я же говорю, — второе счастье по тому, что пересборка кода осуществляется чаще, чем его первичная сборка.
А на счет папочек в .gitignore все зависит от CM инженера. Либо он настраивает права пользователей и хуки, либо он отдает все на откуп инженерам команды разработчиков.
Товарищ Сухов сказал: «Лучше конечно помучиться.»
В этом случае CM инженер решит поставлять в каждую ветку проекта конкретные, фиксированыые ревизии интерфейсного модуля и постарается запретить любые комиты со стороны разработчиков. Только при переходе на новую версию интерфейсного модуля, все остальные команды создадут новые ветки собственных модулей, подключат к ним новую версию интерфейсного модуля и начнут работать над собственным кодом с целью приведения его в соответствие новой версии интерфейсов.
Согласитесь, что при данном подходе интерфейсный модуль лучше всего подключать не как submodule, обвязывая его хуками, а как subtree (а вот нужна ли при этом история интерфейсного модуля в общем индексе, это уже другой вопрос).