История изменений
Исправление swwwfactory, (текущая версия) :
нет, при пуле в хост-репу когда я тяну изменения из хоума репо которое подключено как поддерево
А зачем тебе тянуть так?
Дано: 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 со всеми рабочими циклами.
Исправление swwwfactory, :
нет, при пуле в хост-репу когда я тяну изменения из хоума репо которое подключено как поддерево
А зачем тебе тянуть так?
Дано: 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 т.к. у тебя это дерево уже выделено изначально как subtree в proj1.1-bind-subtree, а в proj1.2 пока нет. Но это можно сделать в любой момент.
Важно понимать следующее. DCVS это распределенная система по определению. Левая рука не ведает что творит правая фактически. Каждый отвечает только за свою локальную репу в основном. Нельзя командовать чужой репой - только push/pull/merge
Будет совсем сложно - сделаю рабочий пример использования subtree со всеми рабочими циклами.
Исправление swwwfactory, :
нет, при пуле в хост-репу когда я тяну изменения из хоума репо которое подключено как поддерево
А зачем тебе тянуть так?
Дано: 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.2
Далее
proj1.2
* делаешь просто pull из proj1-repo
* subtree у тебя уже в проекте - работаешь прозрачно с ним
* фактически тут можно забыть о нем, но можно и git remote add... его и далее pull из home-subtree.
* Лучше сделать просто push в proj1-repo и там уже запушить результаты изменений в деревце в home-subtree т.к. у тебя это дерево уже выделено изначально как subtree в proj1.1-bind-subtree, а в proj1.2 пока нет. Но это можно сделать в любой момент.
Важно понимать следующее. DCVS это распределенная система по определению. Левая рука не ведает что творит правая фактически. Каждый отвечает только за свою локальную репу в основном. Нельзя командовать чужой репой - только push/pull/merge
Будет совсем сложно - сделаю рабочий пример использования subtree со всеми рабочими циклами.
Исходная версия swwwfactory, :
нет, при пуле в хост-репу когда я тяну изменения из хоума репо которое подключено как поддерево
А зачем тебе тянуть так?
Дано: 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.2
Далее
proj1.2
* делаешь просто pull из proj1-repo
* subtree у тебя уже в проекте - работаешь прозрачно с ним
* фактически тут можно забыть о нем, но можно и git remote add... его и далее pull из home-subtree.
* Лучше сделать просто push в proj1-repo и там уже запушить результаты изменений в деревце в home-subtree т.к. у тебя это дерево уже выделено изначально как subtree в proj1.1-bind-subtree, а в proj1.2 пока нет. Но это можно сделать в любой момент.
Важно понимать следующее. DCVS это распределенная система по определению. Левая рука не ведает что творит правая фактически. Каждый отвечает только за свою локальную репу в основном. Нельзя командовать чужой репой - только push/pull/merge
Будет совсем сложно - сделаю рабочий пример использования subtree со всеми рабочими циклами.