LINUX.ORG.RU

История изменений

Исправление 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 со всеми рабочими циклами.