Несколько git subtree в одной директории

да без проблем и сколько угодно

ништяк. вечерком буду «переезжать»

Расскажи потом, на какой структуре репы остановился, пожалуйста

могу показать что хочу получить :)

Обычно желаемое отличается от полученного )

Дай угадаю:

MyProj/
    .git/
    3rdparty/
        sub_proj1/
        sub_proj2/
    src/
    include/

Обычно желаемое отличается от полученного )

после года разработки я точно знаю что нужно

.
├── build
│   ├── lib
│   ├── output
│   ├── sdh
│   └── tmp
│       ├── i18n-reference
│       └── i18n-storage
├── logs
└── src
    ├── app
    ├── core // это submodule
    │   ├── build
    │   └── src
    │       ├── core
    │       ├── extension
    │       ├── resources
    │       ├── runner
    │       └── vendor
    │           ├── es5-shim
    │           │   └── tests
    │           │       ├── helpers
    │           │       ├── lib
    │           │       └── spec
    │           └── json
    ├── modules
    │   └── asvm // это submodule
    │       └── src
    │           ├── app
    │           ├── core
    │           ├── resouces
    │           └── vendor
    │               └── cryptojs
    │                   │
    │                   ...
    ├── resources
    └── tasks // здесь и будет "месиво" из subtrees

340 directories

только я делал для своих нужд так: все, что относится к subtree положить в отдельную папку (как работать в subtree, когда файлы смешаны не пробовал. Но гиту главное указать папку в которой лежит под-дерево. Не стал возиться сделал очевидно - subtree лежит в отдельной папке типа src/my-subtree1)

Начни с этого мануала:

https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

проверь git subtree (это раньше не входило в гит)

Если его нет в ядре гита, потом поставь и настрой плагин к гиту: https://github.com/apenwarr/git-subtree.git (поищи новое если что, настраивал себе давно - за это время может уже что-то менялось и обещали этот плагин встроить гит (вроде уже встроили))

Далее, если в ядре нет - продолжение: Поставить плагин подразумевается его подключить прямо к гиту (скопировать, если его там нет в /usr/libexec/git-core/git-subtree или куда еще, где видит гит плагины)

Наиболее сложный момент это push обратно в subtree, pull не вызывал особых проблем.

Общий секрет в том, что:

-тренируешься сначала на кошках (советую 3-4 прогнать цикл, пока не освоишься)

-рекомендую использовать локальный (файловый) репозитарий для твоей subtree оригинальной репы. MY-ORIGIN-ST

-push в MY-ORIGIN-ST делать в отдельную ветку, а уж потом там мержишь её с мастером MY-ORIGIN-ST. Иначе будет ругань (устраняемая), но отдельная ветка более безопасна. (Master вообще лучше не трогать без необходимости особой.) Pull в твой subtree не вызывает особых проблем. (Только тоже лучше pull в отдельную ветку, а потом смержишь - так спокойнее)

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

-Когда будешь делать subtree push подстрахуйся резервной копией: есть риск запушить всю репу в репу под-дерева.

Если в git-core уже включили это плагин, то можно поэкспериментировать pull/push/merge/add прямо с ним - но этого кроме push лично сам не пробовал. Все делал как в мануале. Возможно, с встроенным git subtree все проще, но полезно понимать как это делается сначала без всех команд кроме push (этим плагином делал только эту команду)

subtree очень классная штука и стоит освоения. Решает многие проблеммы интеграции и развертывания проектов.

спс

О! А я невнимательно прочитал. git-subtree не использовал. Видимо, хороший повод поглядеть.

О! А я невнимательно прочитал. git-subtree не использовал. Видимо, хороший повод поглядеть.

если речь о github-проекте, то скорее всего он и послужил основой для команды в ядре git subtree - по сути там то-же самое, но лично сам работал именно с тем скриптом, а с командой новой нет (эта команда появлялась в результате активации скрипта в окружение git).

В общем похоже он так не может. по крайней мере у меня не получилось. гит версии 1.9.Х

vv@vv-Latitude-E5520 /tmp $ mkdir rt2
vv@vv-Latitude-E5520 /tmp $ cd !$
cd rt2
vv@vv-Latitude-E5520 /tmp/rt2 $ git init
Initialized empty Git repository in /tmp/rt2/.git/
vv@vv-Latitude-E5520 /tmp/rt2 $ vim root
vv@vv-Latitude-E5520 /tmp/rt2 $ gt add -A
vv@vv-Latitude-E5520 /tmp/rt2 $ gt ci
[master (root-commit) 470c661] 1st one
 1 file changed, 1 insertion(+)
 create mode 100644 root
vv@vv-Latitude-E5520 /tmp/rt2 $ gt st
# On branch master
nothing to commit, working directory clean
vv@vv-Latitude-E5520 /tmp/rt2 $ 
vv@vv-Latitude-E5520 /tmp/rt2 $ ll
total 4
-rw-rw-r-- 1 vv vv 3 Apr 29 19:32 root
vv@vv-Latitude-E5520 /tmp/rt2 $ git remote add -f r1 file:///tmp/r1
Updating r1
warning: no common commits
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From file:///tmp/r1
 * [new branch]      master     -> r1/master
vv@vv-Latitude-E5520 /tmp/rt2 $ git subtree add --prefix home4subtrees r1 master --squash
git fetch r1 master
From file:///tmp/r1
 * branch            master     -> FETCH_HEAD
Added dir 'home4subtrees'
vv@vv-Latitude-E5520 /tmp/rt2 $ gt st
# On branch master
nothing to commit, working directory clean
vv@vv-Latitude-E5520 /tmp/rt2 $ ls -la
total 36
drwxrwxr-x  4 vv   vv    4096 Apr 29 19:32 .
drwxrwxrwt 24 root root 20480 Apr 29 19:32 ..
drwxrwxr-x  8 vv   vv    4096 Apr 29 19:33 .git
drwxrwxr-x  2 vv   vv    4096 Apr 29 19:32 home4subtrees
-rw-rw-r--  1 vv   vv       3 Apr 29 19:32 root
vv@vv-Latitude-E5520 /tmp/rt2 $ tree
.
├── home4subtrees
│   └── r1f_a
└── root

1 directory, 2 files
vv@vv-Latitude-E5520 /tmp/rt2 $ git remote add -f r2 file:///tmp/r2
Updating r2
warning: no common commits
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From file:///tmp/r2
 * [new branch]      master     -> r2/master
vv@vv-Latitude-E5520 /tmp/rt2 $ 
vv@vv-Latitude-E5520 /tmp/rt2 $ 
vv@vv-Latitude-E5520 /tmp/rt2 $ 
vv@vv-Latitude-E5520 /tmp/rt2 $ git subtree add --prefix home4subtrees r2 master --squash
prefix 'home4subtrees' already exists.
vv@vv-Latitude-E5520 /tmp/rt2 $  

буду рад если не прав..

может 1+ без проблем, что-то не так делаешь. Надо пример повторить как для ядра (в первой ссылке - я так делал, по этому примеру, только потом уж subtree (это не совсем команда, а плагин вошедший в состав ядра гита как плагин) )

У меня 1.8.3.2-r1 версия гита - все работало без проблем.

Начни с «ядерного» примера лучше пока не освоишься, а пуш уже делай через команды git subtree. Потом плавно переключаешься на свой пример.

буду рад если не прав..

что-то не нашел у тебя pull subtree.

Делай как в примере, для начала. Добейся чтобы работал pull из твоей репы и назначенной удаленной ветки для subtree, потом, когда освоишься попробуй push subtree в отдельную ветку удаленной репы, где обитает твое subtree. Там смержишься если нужно с master.

я немного разобрался.

сабж из ОП таки действительно возможен. твоя ссылка как и позволяет положить несколько деревьев в одну диру. новые изменения в subtree home прекрасно «забираются» с помощью pull. при этом я так и не сумел сделать пуш изменей сделанных в subtree в его ремоут

с помощью этого мана http://jeffbeeman.com/node/320 все ок с пушем, но он не может требования из ОП.

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

поздравляю - первый уровень этого квеста пройден :) - иногда достаточно pull-а :)

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

с помощью этого мана http://jeffbeeman.com/node/320 все ок с пушем, но он не может требования из ОП.

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

В общем надо сделать ветку в том «репо» на который указывает remote твоего добавленного subtree - именно ветку т.к. с master-веткой это не прокатит. Далее делаешь push в созданную ветку, и там уже локально делаешь с ней что хочешь, например мердж с master-ом

Почему не прокатит?

Почему не прокатит?

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

и всего-то? дай плз ссьілку на пример/доку

и всего-то? дай плз ссьілку на пример/доку

сейчас не помню уже - когда гит нецензурно ругался на попытку пуша в удаленную ветку master, он ссылался на опцию в конфиге: что-то про allow remote. Вот её надо поправить - тогда пуш в мастер будет. Но, разумеется может у тебя другая ситуация и ошибка. Зачем тебе master? Сделай сначала с добавочной веткой - потом настроишь на master, когда убедишься в рабочем варианте.

http://stackoverflow.com/questions/13756055/git-subtree-subtree-up-to-date-bu... ? Оно?

search:// git subtree push master

вроде оно.

я надеялся что пользоватся subtree будет не сложнее чем submodule. а на деле оказалось совсем не так. напоминает общую картину с гитом: можна все, но нужен шаман, бубен, и талмуд. первую строчку из мана он все еще оправдывает

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

Когда несколько разработчиков или разных под-проектов - subtree очень прозрачен. Там, где он не нужен - просто воспринимается как единая часть. Где надо - подключается subtree (хотя в подключении есть нюансы, но в отличии от модулей, не нужно их снова подключать для обычного развертывания проекта, а просто сделать обычный git pull)

а можно как-то добится чтобы небыло мерджей? хотелось бы линейную историю.

а можно как-то добится чтобы небыло мерджей? хотелось бы линейную историю.

при push в репу сабтри?

а можно как-то добится чтобы небыло мерджей? хотелось бы линейную историю.

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

бля.. модули депрекейтед. когда-нибуть они будут удалены.. :(

нет, при пуле в хост-репу когда я тяну изменения из хоума репо которое подключено как поддерево

ахренеть. чем дальше в лес, тем ...

а там тоже есть?

//я еще пуш так и не осилил. нету времени

нет, при пуле в хост-репу когда я тяну изменения из хоума репо которое подключено как поддерево

А зачем тебе тянуть так?

Дано: home-subtree, proj1.1-bind-subtree, proj1.2, proj1-repo. Где proj1-repo это репа для клонирования проектов типа proj1.1 proj1.2 (по сути они идентичны в начале и далее имеют одну кодовую базу)

init:

proj1.1-bind-subtree

* делаешь там add как в документации из kernel.org - фактически биндишь первый раз туда дерево

* делаешь push в репу proj1-repo

Далее

proj1.2

* делаешь просто pull из proj1-repo

* subtree у тебя уже в проекте - работаешь прозрачно с ним

* фактически тут можно забыть о нем, но можно и git remote add... его и далее pull из home-subtree.

* Лучше сделать просто push в proj1-repo и там уже запушить результаты изменений в деревце в home-subtree из proj1.1-bind-subtree т.к. у тебя это дерево уже выделено изначально как subtree в proj1.1-bind-subtree, а в proj1.2 пока нет. Но это можно сделать в любой момент.

Важно понимать следующее. DCVS это распределенная система по определению. Левая рука не ведает что творит правая фактически. Каждый отвечает только за свою локальную репу в основном. Нельзя командовать чужой репой - только push/pull/merge

Будет совсем сложно - сделаю рабочий пример использования subtree со всеми рабочими циклами.

нет, при пуле в хост-репу когда я тяну изменения из хоума репо которое подключено как поддерево

А зачем тебе тянуть так?

так в доке, той что ты дал ссылку.

даже после начального импорта получается мердж

2014-05-02 11:32 Vasyl Zuzyak       M─┐ [master] Merge r1 project as our subdirectory
2014-05-02 11:29 Vasyl Zuzyak       │ o [r1/master] r1: #2
2014-05-02 11:28 Vasyl Zuzyak       │ I r1: step1
2014-05-02 11:31 Vasyl Zuzyak       I host: in common
2014-05-02 11:31 Vasyl Zuzyak       I host: root

тоже самое после последующих пулов

2014-05-02 11:36 Vasyl Zuzyak       M─┐ [master] Merge branch 'master' of file:///tmp/st1 
2014-05-02 11:35 Vasyl Zuzyak       │ o [r1/master] st1: #3
2014-05-02 11:34 Vasyl Zuzyak       o │ root: bye
2014-05-02 11:32 Vasyl Zuzyak       M─┤ Merge r1 project as our subdirectory
2014-05-02 11:29 Vasyl Zuzyak       │ o r1: #2
2014-05-02 11:28 Vasyl Zuzyak       │ I r1: step1
2014-05-02 11:31 Vasyl Zuzyak       I host: in common
2014-05-02 11:31 Vasyl Zuzyak       I host: root

верхний коммит был сделан как раз в результате выполнения комманды №5

$ git remote add -f Bproject /path/to/B <1>
$ git merge -s ours --no-commit Bproject/master <2>
$ git read-tree --prefix=dir-B/ -u Bproject/master <3>
$ git commit -m "Merge B project as our subdirectory" <4>

$ git pull -s subtree Bproject master <5>

после 4-го пункта абзац выделен - 1-5 делаешь один раз, а потом только pull -s subtree для «подлива».

Тоже делаешь, если нужно в proj1.2 - иначе просто тянешь/клонирешь или пулишь репу из proj1-repo

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

это я понял

и вот здесь мы закончили там где и начали :)

для нетривиальных хотелок нет простых и элегантных решений

и вот здесь мы закончили там где и начали :)
для нетривиальных хотелок нет простых и элегантных решений

Разумеется :)

Или почему бы не так сделать?

...
└── tasks
       subtree1
       subtree2
       ...
       subtreeN
...

Мердж - это полу-автоматная вещь, где гит не может принять решение за человека, какой части кода отдать предпочтение. Можно хотя указать merge strategy, но и в этом случае возможны конфликты. Теоретически гит можно настроить так, что все конфликты будут игнорироваться.

Может тебе делать build просто тогда и bare в помощь?

и вот здесь мы закончили там где и начали :)

т.е. у тебя весь код из разных источников в одном «плоском» каталоге?

да

из ОП

Несколько git subtree в одной директории

возможен ли сабж?

Или почему бы не так сделать?

для этого нужно немного похачить билд файл. который используется еще в нескольких местах и там он уже работает.

сейчас у меня такая ситуация что понимаю что то что сейчас — плохо. а наилучшее решение пока не вижу..

сейчас у меня такая ситуация что понимаю что то что сейчас — плохо. а наилучшее решение пока не вижу..

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