подпроект в git

Submodule кажется логичнее.

Хочу фичу типа svn:externals в git.

Все эти sub-tree и git modules даже близко по удобству с svn не стоят. Одна боль и страдания. Менее больно — общую часть сделать отдельной библиотекой со своим релизным циклом и рассматривать ее как стороннюю зависимость.

Менее больно — общую часть сделать отдельной библиотекой со своим релизным циклом и рассматривать ее как стороннюю зависимость.

А в репозиторий-то как включить?

Я вот тут посмотрел http://git-scm.com/book/en/v2/Git-Tools-Submodules . Чё-то как-то совсем сложно получается и вообще неудобно.

А в репозиторий-то как включить?

Включать надо не в репозиторий, а в проект. КО думает что используя распространенные практики, принятые для вашего языка/платформы.

Ага, это дофига неудобно, но пока ничего более приличного нет.

sub tree не вариант что ли? Вроде по описанию попроще будет.

subtree, насколько я понял, можно только из ветки того же репозитория сделать

subtree, насколько я понял, можно только из ветки того же репозитория сделать

Вообще то гиту пофигу от какого remote ветка.

Я дико извиняюсь, но в Mercurial это сделано просто как тапок, сам пользовался длительное время. Есть git и svn subrepo + thg эту фишку тоже поддерживает :) Понимаю как нелогично выглядит реклама hg в теме о git, но всё же... Может специфика проекта позволит рассмотреть даже такую альтернативу.

Можно объяснить, чем submodule будет логичнее?

Не смешивается история, коммитить в субмодуль проще.

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

Меня от этого subtree чуть кондратий не схватил.

Есть некие общие классы, которые хочется использовать в двух проектах. Как расшарить их на оба репозитория?

Есть другие варианты с гитом?

submodule должен быть в отдельном репозитории, так?

Да.

Меня вот эта фраза со SO отпугивает:

Submodules are easy to set up, but all users have to manage the submodules, which are not automatically included in checkouts (or clones).

Я submodule юзал.

Почему это тебя пугает?

git submodule init && git submodule update

т.е. при обычном git pull изменения не подтянутся, так?

Тогда сабмодуль, да.

Не-а, нужно делать git submodule update --remote --merge.

ok, спс. Вечером попробую замутить..

Положить их все в один репозиторий и сделать структуру вида:

/contrib
/util
/foo
/bar
/project_1
/project_2

Положить их все в один репозиторий

Пока не думаю, что в этом есть смысл.

Есть другие варианты с гитом?

Для каждого проекта делать отдельные git репозиторий, собирать библиотеки, публиковать ( хоть в local maven) одни для других, как зависимости.

Может кто-то знает как лучше, мне не попадалось.

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

$ gradle test install
:compileJava
:compileGroovy
:processResources
:classes
:compileTestJava
:compileTestGroovy
:processTestResources
:testClasses
:test
:jar
:install

все собралось, протестировалось и отправилось в репу.

git submodule init && git submodule update

проще так

 git submodule update --init

Подрепозиторий в git

Не очень понятно, почему бы не использовать просто ещё 1 реп.