У меня есть локальное "документохранилище". Иерархической структуры в соответствии с тематикой.
Решил преобразовать его в GIT репозиторий, чтобы поиметь историю и возможность распределённой модификации.
Проблема в том, что часть содержимого — это другие GIT репозитории.
Хочется иметь их полную локальную копию (т.е. submodules не годятся) + возможность просматривать историю.
Для просмотра использую Tortoise GIT.
В первом приближении эта задача решилась использованием git subtree (без --squash).
Но есть фатальный недостаток — история слилась в один монолитный кусок.
Попробовал перед добавлением поддеревьев создавать ветки.
Стало чуть лучше, коммиты теперь каждый в своей ветке.
Но всё равно плохо:
1) в master все коммиты подряд
2) при переключении на ветку поддерева тоже все коммиты подряд
ВОПРОС:
Как организовать вложенные репозитории, чтобы просматривать их историю независимо друг от друга и независимо от родительского репозитория ?
Идеально если вложенные репозитории можно будет модифицировать и обновлять из их remote источника. Коммиты в remote не требуются.
Здравствуйте, IID, Вы писали:
IID>Хочется иметь их полную локальную копию (т.е. submodules не годятся)
Как сабмодули мешают иметь полную локальную копию? Сабмодуль — это по сути обычный репозиторий, с ним можно работать как с обычным репозиторием.
IID>ВОПРОС: IID>Как организовать вложенные репозитории, чтобы просматривать их историю независимо друг от друга и независимо от родительского репозитория ? IID>Идеально если вложенные репозитории можно будет модифицировать и обновлять из их remote источника. Коммиты в remote не требуются.
Вроде бы сабмодули именно так и работают.
Заходишь в сабмодуль делаешь pull, потом идешь в родительский репозиторий делаешь stage/commit, чтобы сдвинуть указатель.
Можно итерироваться по сабмодлям и в цикле какие-то команды вызывать. Ну там забрать везде из remote по умолчанию и запушить всё на другой remote например.
Здравствуйте, Рома Мик, Вы писали:
РМ>Как сабмодули мешают иметь полную локальную копию? Сабмодуль — это по сути обычный репозиторий, с ним можно работать как с обычным репозиторием.
Сабмодуль это всего лишь указатель.
Репозиторий с библиотекой — на флешке. Работа ведётся в локальных клонах.
И при очередном клонировании может оказаться, что внешнего сабмодуля уже не существует.
Чтобы это победить придётся сделать клон всех нужных репозиториев. И эти клоны объявить сабмодулями.
Обновлять, соответственно, в 2 этапа. Сначала pull в клонах. А потом уже pull обновлённых сабмодулей в мастер-репозитории.
Считаешь, это более правильный вариант, нежели сабдеревья ?
Здравствуйте, IID, Вы писали:
IID> Как организовать вложенные репозитории, чтобы просматривать их историю независимо друг от друга и независимо от родительского репозитория ? git log subfolder_with_other_repo чем плох?
Здравствуйте, IID, Вы писали:
IID>Хочется иметь их полную локальную копию (т.е. submodules не годятся) + возможность просматривать историю.
Сабмодули именно для этого и годятся
IID>ВОПРОС: IID>Как организовать вложенные репозитории, чтобы просматривать их историю независимо друг от друга и независимо от родительского репозитория ? IID>Идеально если вложенные репозитории можно будет модифицировать и обновлять из их remote источника. Коммиты в remote не требуются.
Можно просто папки вложенных репозиториев скопировать и добавить их в .gitignore в родительском репозитории, можно добавить как сабмодули.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, IID, Вы писали:
IID>>Сабмодуль это всего лишь указатель. S>Это для родителя. Сам по себе репозиторий-сабмодуль полноценный.
Суть в том, что мой репозиторий предполагает клонирование на разные машины.
Понадобилась мне документация, где угодно, — склонировал, воспользовался.
Соответственно, в момент очередного клонирования сторонний репозиторий (сабмодуль) может быть уже удалён.
Здравствуйте, IID, Вы писали:
IID>Суть в том, что мой репозиторий предполагает клонирование на разные машины. IID>Понадобилась мне документация, где угодно, — склонировал, воспользовался.
IID>Соответственно, в момент очередного клонирования сторонний репозиторий (сабмодуль) может быть уже удалён.
Ровно так же как и источник клонировния может быть удален Это не техническая проблема. Никто тебе не мешает сабмодули хранить на подконтрольном тебе хостинге.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, IID, Вы писали:
IID>> Как организовать вложенные репозитории, чтобы просматривать их историю независимо друг от друга и независимо от родительского репозитория ? ·>git log subfolder_with_other_repo чем плох?
В случае создания subtree в своих ветках (и слития их потом в мастер) — вообще ничего не говорит. Ни в мастер-ветке, ни в ветке создания subtree.
C:\3\docs>git checkout master
Already on 'master'
Your branch is ahead of 'origin/master' by 11828 commits.
(use "git push" to publish your local commits)
C:\3\docs>git log Hardware\Displays\Retina display\iPad3_lcd
C:\3\docs>git checkout subrep-iPad3_lcd
Switched to branch 'subrep-iPad3_lcd'
C:\3\docs>git log Hardware\Displays\Retina display\iPad3_lcd
А вот список коммитов, которые я хочу видеть:
C:\3\docs>git log 4d3073aa591a08193489485acd151572054ff1cc
commit 4d3073aa591a08193489485acd151572054ff1cc
Author: Andrzej Surowiec <emeryth@gmail.com>
Date: Sat Jun 1 15:21:11 2013 +0200
Added Kicad design of new PCB. Reorganized the repo.
commit 6dc4d11bdf98cb124ac98baaf6e926e5202b6883
Author: Andrzej Surowiec <emeryth@gmail.com>
Date: Thu May 9 01:03:38 2013 +0200
This version sent off to the fab
commit 81ab63383920cf85cc06f885f6519e16dba2b78d
Author: Andrzej Surowiec <emeryth@gmail.com>
Date: Wed May 8 01:24:30 2013 +0200
Changed outline width
commit 5956af09d2daee29b6d2d4fe72e100212edfd762
Author: Andrzej Surowiec <emeryth@gmail.com>
Date: Wed May 8 00:32:11 2013 +0200
Board probably ready
commit 62d40d732935e08103cf001f588eb0b505bcaa2f
Author: Andrzej Surowiec <emeryth@gmail.com>
Date: Mon May 6 01:09:52 2013 +0200
New PCB in Kicad
commit 5fbbfd07eff2593d2dd1f2d3970887252fb309be
Author: Andrzej Surowiec <emeryth@gmail.com>
Date: Sat Apr 20 16:01:11 2013 +0200
Added readme
commit 3690b1213f258a1e163fc519d30dfd53d77956ad
Author: Andrzej Surowiec <emeryth@gmail.com>
Date: Sat Apr 20 15:03:57 2013 +0200
Здравствуйте, Skorodum, Вы писали:
S>Ровно так же как и источник клонировния может быть удален
Источник клонирования находится в моём владении, и его временем жизни управляю я.
Источник сабмодулей мне не подчиняется.
S>Это не техническая проблема. Никто тебе не мешает сабмодули хранить на подконтрольном тебе хостинге.
Я думал об этом, и даже писал выше по этому треду.
Минус в том, что обновление придётся делать в 2 этапа. Сначала в зеркале сабмодулей. Потом в репе, использующей зеркало.
В целом изначальную проблему можно переформулировать другим образом: как просматривать коммиты в ветке, отсекая все сторонние ветки при этом ?
Потому что сейчас я в каждой ветке, в которой создавался subtree, вижу историю всего репозитория на момент создания этой ветки.
Возможно историю портит использование subtree, но не уверен.
Здравствуйте, Skorodum, Вы писали:
S>Можно просто папки вложенных репозиториев скопировать и добавить их в .gitignore в родительском репозитории
Так и происходит by-default. Вместо вложенного репозитория пушится только его пустая папка.
Можно ещё круче поступить — вообще не использовать средства GIT, а создать зеркало внешних репозиториев (напр. "externals"), а в своём репозитории только симлинки проставить на него.
Заодно:
— симлинки можно проставить и внутри самого external, сгруппировав репозитории по автору, технологии, предметной области, типу проекта и т.д.
— масштабируется на неограниченное число своих репозиториев.
Здравствуйте, IID, Вы писали:
IID>Я думал об этом, и даже писал выше по этому треду. IID>Минус в том, что обновление придётся делать в 2 этапа. Сначала в зеркале сабмодулей. Потом в репе, использующей зеркало.
Зеркало сабмодулей нужно только как бэкап на случай если оригинал станет не доступен. Его можно синхронизировать как-то автоматически и вообще про него забыть до часа "Х". Да и если у тебя read-only права вряд ли тебе всегда нужна самая последняя версия, так что и двойное обновление не проблема.
IID>В целом изначальную проблему можно переформулировать другим образом: как просматривать коммиты в ветке, отсекая все сторонние ветки при этом ? IID>Потому что сейчас я в каждой ветке, в которой создавался subtree, вижу историю всего репозитория на момент создания этой ветки. IID>Возможно историю портит использование subtree, но не уверен.
Ну вроде как subtree именно так и работает Судя по разным правам доступа, твои сабмодули это полноценные отдельные проекты, поэтому сабмодули тут более логичны.
"initial commit" — мой самый первый коммит, когда я заливал содержимое библиотеки в GIT
"fix nested GIT subreps" — это коммит, удаляющий пустые папки под-проектов.
ну и последним идёт коммит добавления subtree
Здравствуйте, IID, Вы писали:
IID>>>Сабмодуль это всего лишь указатель. S>>Это для родителя. Сам по себе репозиторий-сабмодуль полноценный. IID>Суть в том, что мой репозиторий предполагает клонирование на разные машины. IID>Понадобилась мне документация, где угодно, — склонировал, воспользовался. IID>Соответственно, в момент очередного клонирования сторонний репозиторий (сабмодуль) может быть уже удалён.
Кажется, я понял что ты хочешь. Это действительно не совсем просто с сабмодулями. С subtree дела не имел, но возможно оно лучше для этого подходит.
С сабмодулями, если ты не редактируешь файлы на флешке, а используешь ее только как remote, то можно склонировать на нее отдельно основной проект, отдельно все подпроекты. Добавить в основной проект сабмодули с относительными url. Не надо вызывать там submodule update, это не смертельно, но у тебя будут лишние ненужные копии этих репозиториев внутри папки основного репозитория. На компьютере куда хочешь склонировать, вызываешь clone, потом submodule update. И на этом компьютере сабмодули будут уже внутри папки основного репозитория. Там можно редактировать, коммитить, пушить на флешку.
Здравствуйте, Рома Мик, Вы писали:
РМ>Кажется, я понял что ты хочешь. Это действительно не совсем просто с сабмодулями. С subtree дела не имел, но возможно оно лучше для этого подходит. РМ>С сабмодулями, если ты не редактируешь файлы на флешке, а используешь ее только как remote, то можно склонировать на нее отдельно основной проект, отдельно все подпроекты. Добавить в основной проект сабмодули с относительными url. Не надо вызывать там submodule update, это не смертельно, но у тебя будут лишние ненужные копии этих репозиториев внутри папки основного репозитория. На компьютере куда хочешь склонировать, вызываешь clone, потом submodule update. И на этом компьютере сабмодули будут уже внутри папки основного репозитория. Там можно редактировать, коммитить, пушить на флешку.
Я в итоге решил сделать "гибрид".
Для проектов с небольшим числом коммитов — слить как subtree. Они как раз небольшие, малоизвестные, редко находятся и почти никогда не обновляются.
Для крупных проектов, с активной разработкой и кучей коммитов — сделать свои клоны и юзать как сабмодули.
Здравствуйте, IID, Вы писали:
IID>·>Попробуй так IID>·>git log --follow "Hardware\Displays\Retina display\iPad3_lcd" IID>Попробовал. Получил дубли двух старых коммитов.
Мда... В общем-то понятно почему оно так — файлы переместились.
Как я понимаю git log 4d3073aa5 выдаст что ты хочешь (можешь бранч создать для этого коммита), но как-то неудобно получается использовать и совсем неудобно станет, если subtree будут ещё потом re-merge делаться.
submodule думаю будет удобнее использовать. Просто храни клоны внешних реп на флешке в соседней дире и используй relative path из родительского репо. Для вытягивания последних изменений из внешних источников — делай pull из них, потом push себе на флешку. Вроде Рома Мик предлагает то же самое.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Как я понимаю git log 4d3073aa5 выдаст что ты хочешь (можешь бранч создать для этого коммита)
совершенно верно
·>но как-то неудобно получается использовать и совсем неудобно станет, если subtree будут ещё потом re-merge делаться.
и это тоже
·>submodule думаю будет удобнее использовать. Просто храни клоны внешних реп на флешке в соседней дире и используй relative path из родительского репо. Для вытягивания последних изменений из внешних источников — делай pull из них, потом push себе на флешку. Вроде Рома Мик предлагает то же самое.