Видимо, не я один столкнусь с проблемой включения mainstream'ом submodules. Предлагается добавить поддержку в gear submodules (а точнее - в gear-command-tar. Сделать это можно, взяв за основу этот скрипт: http://github.com/meitar/git-archive-all.sh/tree/master
Я сам submodules пока ещё не использую, так что ничего сказать не могу.
мне тоже вот понадобилось. хорошо бы реализовать.
Чтобы реализовать, хочется понять что нужно. Можно подробнее о том, где понадобилось ?
ммм... ну собственно в git с submodules и понадобилось :-) если есть git репозиторий с сабмодулями, то хотелось бы не пользоваться объездными путями (как например создание remote branch-ей на примере psi: http://lists.altlinux.org/pipermail/devel/2009-February/166183.html), а просто использовать стандартный .gear/rules если git имеет такую возможность как submodules а "gear спроектирован для сборки пакетов из произвольно устроенного git-репозитория", то хорошо бы чтоб он поддерживал и submodules. я тоже хотел бы задействовать эту фичу git-а (submodule), но остановился на невозможности опакетить (получить тарболл из моего git-репозитория).
Дайте ссылку на интересующий вас проект. Нужен тесткейс.
git://git.psi-im.org/psi.git
Вот попробуйте: http://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=shortlog;h=refs/heads/submodule Что не протестировал: 1. Не пробовал директиву zip. 2. На приведённом тесткейсе не удобно тестировать опцию -t. Так что она тоже не проверена.
Мне пока не ясно как быть с "git submodule update". Сейчас в реализации найдено несколько проблем, которые нужно осмыслить и исправить.
Протестировал и исправил директиву zip, но для этого в gear предётся пользоваться zipmerge (из пакета libzip).
Прошу проверить текущее состояние бранча. Все вопросы сняты.
(В ответ на комментарий №10) > Прошу проверить текущее состояние бранча. Все вопросы сняты. * zip работает * -t работает, правда надо самостоятельно следить за gear submodule update --init на свежесклонированном репоитории. иначе тарболл делается неполный. спасибо!
Интересно, а будет ли это работать в сборочнице ?
(В ответ на комментарий №12) > Интересно, а будет ли это работать в сборочнице ? Нет. Разве git.alt поддерживает submodules ?
А какой тогда в этом смысл ? Впочем, можно повесить багу на сборочницу..
(В ответ на комментарий №11) > * -t работает, правда надо самостоятельно следить за gear submodule update > --init на свежесклонированном репоитории. иначе тарболл делается неполный. Другого способоа я не вижу. Запуск "git submodule update -N -i" из gear приведёт к изменению рабочей копии репозитория и даже потере изменений.
(В ответ на комментарий №14) > А какой тогда в этом смысл ? gear != git.alt Бага повешена на gear и я реализовал поддержку submodules в нём. Для git.alt пусть кто-нибудь тоже реализуюет поддержку. Я этого сделать не могу. Но без поддержки в gear нет смысла добавлять что-то в git.alt
(В ответ на комментарий №16) > Но без поддержки в gear нет смысла добавлять что-то в git.alt совершенно верно. дополнительный бонус -- уже сегодня можно собираться что-то с submodules у себя локально.
(В ответ на комментарий №14) > А какой тогда в этом смысл ? > > Впочем, можно повесить багу на сборочницу.. повесишь?
Интересно, что мантейнер пакета так и не высказался тут. Дима?
Насколько я понимаю, submodule в git -- это weak reference, т.е. ссылка на sha1-имя коммита, и ничто не гарантирует наличие этого коммита в репозитории. Если это так, то для того, чтобы submodules можно было использовать в gear, нужно как-то реализовать эту гарантию, например, обеспечить попадание этого sha1 в историю, наподобие gear-update-tag.
насколько я понял - это скоре несколько иное - ссылка на SHA1 коммит во внешнем репозитарии, который выкачивается каждый раз, когда говорится git submodule init и git submodule update Собственно про это сказано тут: update Update the registered submodules, i.e. clone missing submodules and checkout the commit specified in the index of the containing repository. This will make the submodules HEAD be detached. If the submodule is not yet initialized, and you just want to use the setting as stored in .gitmodules, you can automatically initialize the submodule with the --init option.
(В ответ на комментарий №20) > Насколько я понимаю, submodule в git -- это weak reference, т.е. ссылка на > sha1-имя коммита, и ничто не гарантирует наличие этого коммита в репозитории. В подрепозитории ? Да. не гарантирует. Для этого и есть команда "git submodule update", которая если нужно клонирует подрепозиторий и делает checkout. > Если это так, то для того, чтобы submodules можно было использовать в gear, > нужно как-то реализовать эту гарантию, например, обеспечить попадание этого > sha1 в историю, наподобие gear-update-tag. Не понял о чём ты. git и так сам отслеживает состояние таких ссылок и через "git submodule status" показывает их состояние. Вот как хранится ссылка: $ git ls-tree HEAD |grep '^160000 ' 160000 commit c9e824912f7c4f7c13fbfdb4e9a583db2938a141 iris
(В ответ на комментарий №20) > Насколько я понимаю, submodule в git -- это weak reference, т.е. ссылка на > sha1-имя коммита, и ничто не гарантирует наличие этого коммита в репозитории. Чтобы гарантировать наличие коммита в репозитории нужно сказать: git submodule update --init но это может привести к потери коммитов в подрепозиториях, если ссылка в основном репозитории не была обновлена. Поэтому я не стал это делать.
Сейчас, без использования submodule, команда вроде GIT_DIR=/path/to/repo.git gear -t v1.0 out.tar работает всегда, поскольку все необходимые объекты гарантированно присутствуют в репозитории, в котором есть этот v1.0 Привнесение поддержки submodule не должно сломать эту гарантию.
(В ответ на комментарий №24) > Сейчас, без использования submodule, команда вроде > GIT_DIR=/path/to/repo.git gear -t v1.0 out.tar > работает всегда, поскольку все необходимые объекты гарантированно присутствуют > в репозитории, в котором есть этот v1.0 > > Привнесение поддержки submodule не должно сломать эту гарантию. Будет ли достаточно, если gear будет оказываться работать при отсутствии объектов? Я лично думаю, что такое поведение допустимо.
(In reply to comment #25) > (В ответ на комментарий №24) > > Сейчас, без использования submodule, команда вроде > > GIT_DIR=/path/to/repo.git gear -t v1.0 out.tar > > работает всегда, поскольку все необходимые объекты гарантированно присутствуют > > в репозитории, в котором есть этот v1.0 > > > > Привнесение поддержки submodule не должно сломать эту гарантию. > > Будет ли достаточно, если gear будет оказываться работать при отсутствии > объектов? Сейчас, без submodules, git (и gear вслед за ним) отказывается работать без необхоимых объектов, и это правильно. Существенное отличие заключается в том, что сейчас, без submodules, нет штатного способа зафетчить или запушить коммит без необходимых для него объектов. А вот в случае добавления поддержки submodule, наоборот, не будет штатного способа зафетчить и запушить коммит со всеми необходимыми для него объектами. Это не нарушает принцип необратимости истории коммита, но нарушает принцип достаточности коммита. Я сейчас вижу только один способ решения этой проблемы: fake merge.
(В ответ на комментарий №26) > Сейчас, без submodules, git (и gear вслед за ним) отказывается работать без > необхоимых объектов, и это правильно. Репозитории используют механизм submodules и нам предётся вслед за git учиться с ним работать, если мы хотим дать возможность пользователям держать апстримный git и использовать gear как надстройку для запаковки (чем сейчас и является gear). > Я сейчас вижу только один способ решения этой проблемы: fake merge. Ты имеешь ввиду делать из submodules делать subtree ?
(In reply to comment #27) > (В ответ на комментарий №26) > > Сейчас, без submodules, git (и gear вслед за ним) отказывается работать без > > необхоимых объектов, и это правильно. > > Репозитории используют механизм submodules и нам предётся вслед за git учиться > с ним работать, если мы хотим дать возможность пользователям держать > апстримный git и использовать gear как надстройку для запаковки (чем сейчас и > является gear). Механизм submodules позволяет создавать коммиты, из которых без доступа в интернет в принципе нельзя собрать правильный тарболл. Если пользователи будут создавать такие коммиты, они не смогут использовать gear для сборки из них. > > Я сейчас вижу только один способ решения этой проблемы: fake merge. > > Ты имеешь ввиду делать из submodules делать subtree ? Если из submodules делать subtree, то они перестанут быть submodules. Вероятно, нужен некий gear-update-submodules, который будет делать git merge -s ours для всех используемых submodules.
делать из submodules subtree не получится. Есть ровно один выход, и он применён в git.alt/psi т.е. submodule в отдельный branch и паковать его в tarball. Кстати, тут очень бы пригодилось отсутствие проверки merge бранча в HEAD. Опционально. Зачем мне iris мержить в HEAD, если в HEAD лежит только спек и патчи (например) ?
(In reply to comment #29) > делать из submodules subtree не получится. > > Есть ровно один выход, и он применён в git.alt/psi > > т.е. submodule в отдельный branch и паковать его в tarball. Это можно сделать, и это даже лучше, но это ведь ручная работа. > Кстати, тут очень бы пригодилось отсутствие проверки merge бранча в HEAD. > Опционально. > > Зачем мне iris мержить в HEAD, если в HEAD лежит только спек и патчи (например) > ? Это же очевидно: если соответствующий коммит из iris не окажется в истории HEAD, то не будет гарантии того, что этот коммит вообще будет присутствовать в репозитории. А если этого коммита не будет в репозитории, то из него не получится собрать тарболл.
(В ответ на комментарий №28) > Если из submodules делать subtree, то они перестанут быть submodules. Именно. Тогда гарантия наличия объектов будет. > Вероятно, нужен некий gear-update-submodules, который будет делать git merge -s > ours для всех используемых submodules. Что-то я совсем запутался. git-merge можно делать только между бранчами. Как ты предполагаешь делать merge между разными репозиториями ?
(In reply to comment #31) > (В ответ на комментарий №28) > > Если из submodules делать subtree, то они перестанут быть submodules. > > Именно. Тогда гарантия наличия объектов будет. Если 160000 commit 6ee41f079a3f3ff0263ab309489cdae0f7b82acb iris превратится в 040000 tree какойтоsha1 iris то это уже не будет submodule. Т.е. тогда это будет поддержка не submodules? > > Вероятно, нужен некий gear-update-submodules, который будет делать git merge -s > > ours для всех используемых submodules. > > Что-то я совсем запутался. git-merge можно делать только между бранчами. Как ты > предполагаешь делать merge между разными репозиториями ? submodule представляет собой ссылку на коммит, а на коммит можно сделать merge. Разве нет?
(В ответ на комментарий №30) > (In reply to comment #29) > > делать из submodules subtree не получится. > > > > Есть ровно один выход, и он применён в git.alt/psi > > > > т.е. submodule в отдельный branch и паковать его в tarball. > > Это можно сделать, и это даже лучше, но это ведь ручная работа. Никакой ручной работы - всё автоматизируется. > > > Кстати, тут очень бы пригодилось отсутствие проверки merge бранча в HEAD. > > Опционально. > > > > Зачем мне iris мержить в HEAD, если в HEAD лежит только спек и патчи (например) > > ? > > Это же очевидно: если соответствующий коммит из iris не окажется в истории > HEAD, то не будет гарантии того, что этот коммит вообще будет присутствовать в > репозитории. А если этого коммита не будет в репозитории, то из него не > получится собрать тарболл. Ну, нормально - если не взял коммит из репозитария, то не получится собрать тарболл. Вполне законно. Это же не получится и локально сделать. Или ты имеешь в виду ситуацию, когда публикуется только master ? без бранчей ?
(In reply to comment #33) > (В ответ на комментарий №30) > > (In reply to comment #29) > > > делать из submodules subtree не получится. > > > > > > Есть ровно один выход, и он применён в git.alt/psi > > > > > > т.е. submodule в отдельный branch и паковать его в tarball. > > > > Это можно сделать, и это даже лучше, но это ведь ручная работа. > > Никакой ручной работы - всё автоматизируется. Автоматизируется только обновления бранча и вызовы git merge с gear-update-tag. Одноразовая ручная работа по прописыванию правил в .spec и .gear/rules никак не автоматизируется, > > > Кстати, тут очень бы пригодилось отсутствие проверки merge бранча в HEAD. > > > Опционально. > > > > > > Зачем мне iris мержить в HEAD, если в HEAD лежит только спек и патчи > > > (например) ? > > > > Это же очевидно: если соответствующий коммит из iris не окажется в истории > > HEAD, то не будет гарантии того, что этот коммит вообще будет присутствовать > > в репозитории. А если этого коммита не будет в репозитории, то из него не > > получится собрать тарболл. > > Ну, нормально - если не взял коммит из репозитария, то не получится собрать > тарболл. Вполне законно. Это же не получится и локально сделать. > > Или ты имеешь в виду ситуацию, когда публикуется только master ? без бранчей ? Нарушается принцип достаточности коммита. Ничто не помешает (и даже не подскажет), какие бранчи нужно запушить, какие бранчи нельзя удалять, и какие бранчи нужно фетчить для того, чтобы собрать из master.
(В ответ на комментарий №34) > > Никакой ручной работы - всё автоматизируется. > > Автоматизируется только обновления бранча и вызовы git merge с gear-update-tag. > Одноразовая ручная работа по прописыванию правил в .spec и .gear/rules никак не > автоматизируется, > Там всё, как правило, однотипно. Более того - я для submodules не ставлю тэгов, не делаю версий. Мне достаточно, что будет просто iris.tar с текущим моим HEAD от бранча iris. Конечно, один раз поправить спек и один раз поправить .gear/rules - придётся. В дальнейшем - только git merge -s ours, и gear-update-tag. В принципе, меня даже merge -s ours не сильно напрягает.. просто не всем удаётся объяснить, зачем это нужно. > > > > Кстати, тут очень бы пригодилось отсутствие проверки merge бранча в HEAD. > > > > Опционально. > > > > > > > > Зачем мне iris мержить в HEAD, если в HEAD лежит только спек и патчи > > > > (например) ? > > > > > > Это же очевидно: если соответствующий коммит из iris не окажется в истории > > > HEAD, то не будет гарантии того, что этот коммит вообще будет присутствовать > > в репозитории. А если этого коммита не будет в репозитории, то из него не > > > получится собрать тарболл. > > > > Ну, нормально - если не взял коммит из репозитария, то не получится собрать > > тарболл. Вполне законно. Это же не получится и локально сделать. > > > > Или ты имеешь в виду ситуацию, когда публикуется только master ? без бранчей ? > > Нарушается принцип достаточности коммита. > Ничто не помешает (и даже не подскажет), какие бранчи нужно запушить, какие > бранчи нельзя удалять, и какие бранчи нужно фетчить для того, чтобы собрать из > master. gear-push ? нужно пушить всё, что есть .gear/tags
(В ответ на комментарий №32) > (In reply to comment #31) > > (В ответ на комментарий №28) > > > Если из submodules делать subtree, то они перестанут быть submodules. > > > > Именно. Тогда гарантия наличия объектов будет. > > Если > 160000 commit 6ee41f079a3f3ff0263ab309489cdae0f7b82acb iris > превратится в > 040000 tree какойтоsha1 iris > то это уже не будет submodule. > Т.е. тогда это будет поддержка не submodules? Если это будет происходить с помощью утилиты одной командой, то это объезд проблемы. > submodule представляет собой ссылку на коммит, а на коммит можно сделать merge. > Разве нет? $ git ls-tree HEAD |grep '^16' 160000 commit c9e824912f7c4f7c13fbfdb4e9a583db2938a141 iris $ git cat-file -p c9e824912f7c4f7c13fbfdb4e9a583db2938a141 error: unable to find c9e824912f7c4f7c13fbfdb4e9a583db2938a141 fatal: Not a valid object name c9e824912f7c4f7c13fbfdb4e9a583db2938a141 Это ссылка на коммит из другого репозитория. И мердж по нему сделать нельзя т.к. сам объект в другом репозитории.
Мы опять скатились к объезду submodules. Да, при их использовании одного коммита в основной репозиторий мало... чтобы собрать пакет нужно дополнительно получить submodule, содержащий объект на который сделана ссылка (git submodule update). Но в этом и есть смысл submodules - не хранить всё в одном репозитории. А мы опять сводим всё к этому. Мне кажется мы смотрим не в ту сторону.
Мне тоже не нравится идея с submodule. Особенно учитывая то, что submodule может быть и через git+ssh или file.
(In reply to comment #36) > $ git ls-tree HEAD |grep '^16' > 160000 commit c9e824912f7c4f7c13fbfdb4e9a583db2938a141 iris > > $ git cat-file -p c9e824912f7c4f7c13fbfdb4e9a583db2938a141 > error: unable to find c9e824912f7c4f7c13fbfdb4e9a583db2938a141 > fatal: Not a valid object name c9e824912f7c4f7c13fbfdb4e9a583db2938a141 > > Это ссылка на коммит из другого репозитория. И мердж по нему сделать нельзя > т.к. сам объект в другом репозитории. Тот, кто может выполнить submodule update, может получить этот коммит с смерджить его.
(В ответ на комментарий №39) > Тот, кто может выполнить submodule update, может получить этот коммит с > смерджить его. Этот коммит у меня есть в подмодуле: $ git --git-dir=iris/.git cat-file -t c9e824912f7c4f7c13fbfdb4e9a583db2938a141 commit Всё ещё не понимаю, как ты мердж предполагаешь делать.
Created attachment 3480 [details] gear-clone Нечто типа этого не может гарантировать наличие всех необходимых объектов? Состояние основного репозитория однозначно описывает состояния его модулей ... даже если этих объектов нет. Вот так это выглядит в основном репозитории: $ git log -n1 -p 6eaceaea9a89153855fd951aa0e1861588dc60e7 commit 6eaceaea9a89153855fd951aa0e1861588dc60e7 Author: Justin Karneges <justin@affinix.com> Date: Fri Apr 17 13:50:27 2009 -0700 update to latest iris diff --git a/iris b/iris index 0d44dbf..6ee41f0 160000 --- a/iris +++ b/iris @@ -1 +1 @@ -Subproject commit 0d44dbfa10fc1f47c1de64c45cde43748dfe44d4 +Subproject commit 6ee41f079a3f3ff0263ab309489cdae0f7b82acb Наша проблема в том, что при клонировании получаются объекты лишь основного репозитория, но не его модулей. Нам нужно рассмотривать основной репозиторий и его модули как связанное целое. Или я не прав?
(In reply to comment #41) > Created an attachment (id=3480) [details] > gear-clone > > Нечто типа этого не может гарантировать наличие всех необходимых объектов? Это может помочь обычному пользователю подготовить репозиторий, содержащий submodules, к сборке gear'ом из HEAD'а. Инструментам, использующим git fetch, это не поможет. > Состояние основного репозитория однозначно описывает состояния его модулей ... > даже если этих объектов нет. Вот так это выглядит в основном репозитории: > > $ git log -n1 -p 6eaceaea9a89153855fd951aa0e1861588dc60e7 > commit 6eaceaea9a89153855fd951aa0e1861588dc60e7 > Author: Justin Karneges <justin@affinix.com> > Date: Fri Apr 17 13:50:27 2009 -0700 > > update to latest iris > > diff --git a/iris b/iris > index 0d44dbf..6ee41f0 160000 > --- a/iris > +++ b/iris > @@ -1 +1 @@ > -Subproject commit 0d44dbfa10fc1f47c1de64c45cde43748dfe44d4 > +Subproject commit 6ee41f079a3f3ff0263ab309489cdae0f7b82acb Да, имена коммитов описывают историю однозначно. > Наша проблема в том, что при клонировании получаются объекты лишь основного > репозитория, но не его модулей. Нам нужно рассмотривать основной репозиторий и > его модули как связанное целое. Да, при всех операциях передачи коммитов из одного репозитория в другой все эти gitlink'и игнорируются, в результате чего репозитории перестают быть самодостаточными. > Или я не прав? Ты прав, конечно, но это этого не легче.
(В ответ на комментарий №42) > (In reply to comment #41) > > Created an attachment (id=3480) [details] [details] > > gear-clone > > > > Нечто типа этого не может гарантировать наличие всех необходимых объектов? > > Это может помочь обычному пользователю подготовить репозиторий, содержащий > submodules, к сборке gear'ом из HEAD'а. > > Инструментам, использующим git fetch, это не поможет. Репозиторий, использующий submodules, однозначно определяется. Поэтому необходимые модули можно однозначно получить: git clone git://git.psi-im.org/psi.git cd psi/ git submodule status -ffe4a38d3f17b3380b060d1cbaafbeedc572c12a iris -09a8aa5fe8217ebe6504785479aad059efcda0d8 src/libpsi git submodule init git submodule update git submodule status ffe4a38d3f17b3380b060d1cbaafbeedc572c12a iris (ffe4a38) 09a8aa5fe8217ebe6504785479aad059efcda0d8 src/libpsi (09a8aa5) Разумеется, те кто хочет использовать только "git fetch" не смогут получить все объекты, необходимые для сборки проекта. Но техника работы с submodule не ставит себе такую цель. Есть дополнительный инструментарий в git, который обеспечивает корректную работу с модулями. Я не вижу технических проблем научить инструменты, использующие "git fetch", дополнительно использовать "git submodule".
(In reply to comment #43) > Разумеется, те кто хочет использовать только "git fetch" не смогут получить все > объекты, необходимые для сборки проекта. Но техника работы с submodule не > ставит себе такую цель. Есть дополнительный инструментарий в git, который > обеспечивает корректную работу с модулями. > > Я не вижу технических проблем научить инструменты, использующие "git fetch", > дополнительно использовать "git submodule". Сначала мы разрешим незамкнутые репозитории, а потом будем пытаться гарантировать замкнутость во всех случаях, где она нужна? Нет, это тупик. Единственный выход, который я вижу -- это принудительный fake merge, который гарантирует замыкание естественным образом.
(В ответ на комментарий №44) > Сначала мы разрешим незамкнутые репозитории, а потом будем пытаться > гарантировать замкнутость во всех случаях, где она нужна? Нет, это тупик. > Единственный выход, который я вижу -- это принудительный fake merge, который > гарантирует замыкание естественным образом. Это противоречит логике git. Модули придуманы для создания зависимостей между репозиториями, не имеющими общей истории и общих объектов. Объединять такие репозитории в корне неправильно. Такой merge превратит репозиторий в помойку. Ограничение "клонировать/использовать submodules вместе с родительским репозиторием" мне кажется правильным решением. gear лишь надстройка над git и может гарантировать выполнение такого ограничения.
(In reply to comment #45) > (В ответ на комментарий №44) > > Сначала мы разрешим незамкнутые репозитории, а потом будем пытаться > > гарантировать замкнутость во всех случаях, где она нужна? Нет, это тупик. > > Единственный выход, который я вижу -- это принудительный fake merge, который > > гарантирует замыкание естественным образом. > > Это противоречит логике git. Не вижу противоречия, скорее наоборот. > Модули придуманы для создания зависимостей между > репозиториями, не имеющими общей истории и общих объектов. Да. > Объединять такие репозитории в корне неправильно. Однако для сборки их просто необходимо объединить, чтобы добыть всё необходимое. Этим сборка проекта отличается от остальных этапов сопровождения исходного кода. > Такой merge превратит репозиторий в помойку. Почему? Каким образом? > Ограничение "клонировать/использовать submodules вместе с родительским > репозиторием" мне кажется правильным решением. gear лишь надстройка над git и > может гарантировать выполнение такого ограничения. gear -- это не надстройка, а инструмент для решения определённой задачи. git умеет гарантировать замыкание, и надо это свойство git использовать, а не пытаться реализовывать замыкание по всей цепочке в gear своими силами. Пакеты должны уметь собираться на отдельно взятом изолированном сервере. Это значит, что на каждом этапе передачи git-репозитория должна быть гарантирована его самодостаточность. Нет более эффективного способа обеспечения этой гарантии, чем использование встроенных в git средств.
из ответа в devel@: > As you see, there is a fundamental problem: GIT submodule breaks > repository completeness, but gear requires git repositories to be > self-contained. I have no idea how to avoid this problem. Исправить ожидания gear на соответствующие наблюдаемой действительности, разумеется. Возможно, обязав заливать используемые для субмодулей репо на git.alt и указывать соответствие где-нить в .gear/submodules во избежание тупой автоматической траты времени и трафика. При этом технический мерж можно делать прямо перед скручиванием тарбола, как понимаю. И репо чистые, и Дима доволен.
(In reply to comment #47) > из ответа в devel@: > > > As you see, there is a fundamental problem: GIT submodule breaks > > repository completeness, but gear requires git repositories to be > > self-contained. I have no idea how to avoid this problem. > > Исправить ожидания gear на соответствующие наблюдаемой > действительности, разумеется. > > Возможно, обязав заливать используемые для субмодулей репо на > git.alt Это не представляется возможным. > и указывать соответствие где-нить в .gear/submodules > во избежание тупой автоматической траты времени и трафика. > > При этом технический мерж можно делать прямо перед скручиванием > тарбола, как понимаю. И репо чистые, и Дима доволен. Сборочный тэг должен указывать на коммит, замыкание которого находится в репозитории целиком и передаётся базовыми операциями (git fetch и git push) без потерь. Всё остальное -- детали реализации.
Беру таймаут.
(In reply to comment #48) > > Возможно, обязав заливать используемые для субмодулей репо на > > git.alt > Это не представляется возможным. Почему? Тогда проблема потенциально длительной/сбойной загрузки уходит, остаётся решить, как удобней сделать технический мерж либо переписать .gitmodules сообразно .gear/submodules. Выдача релевантной диагностики -- в идеале со ссылкой на вики -- будет достаточным напоминанием для того, чтобы майнтейнер спохватился и предпринял требуемое действие.
Я постарался ещё раз осмыслить задачу и понять как её можно решить. Есть данность: существуют репозитории, использующие модули и есть gear, который должен уметь с ними работать. Нам нужно чтобы при клонировании репозиторий был самодостаточным. Что происходит с обычным репозиторием: мы делаем "git clone" и происходит копирование всего дерева объектов. Таким образом при клонировании репозитория от пользователя A к пользователю B, от B к C репозиторий оказывается самодостаточным и нет необходимости при клонировании B -> С иметь доступ к пользователю А: A --> B --> C --> ... Что происходит с "модульным" репозиторием: клонируется родительский репозиторий, но он не замкнут. В нём есть ссылки на объекты из другого репозитория (ссылка на модуль). Ссылки на модули содержатся в файле .gitmodules, который является частью родительского репозитория. Чтобы получить необходимые модули нам нужно выполнить команду "git submodule update", которая получает репозитории модулей по ссылкам. При этом при следующем клонировании ссылки остаются прежними. Таким образом, чтобы собрать родительский репозиторий и модули нужно иметь доступ к серверу, на который установлена ссылка: A ----> B --> C --> ... \-A1 <--------/ \-A2 <--------/ Чтобы использовать такой репозиторий есть несколько путей: 1. Можно использовать "git merge -s subtree". Это поможет при клонировании, но создаст общую историю между всеми репозиториями. Если общая история - не проблема, то это лучший путь. 2. Можно продолжить использовать модули. Для этого нужно исправить особенность формирования ссылок. Мы можем наложить следующее ограничение: модули должны находиться по тому же пути, что и основной репозиторий и на своих местах. Таким образом, при клонировании родительского репозитория будут клонироваться и модули. В этом случае последующее клонирование будет производиться не из первоначального места, а из того же места, что и родительский. Проблемным местом для этого подхода осталось клонирование bare репозиториев. 3. Можно разместить модули в бранчах и средствами gear работать с ними. Тут всё приходится делать вручную ... обновление и распаковку в нужное место. Для всех трёх случаев я сделал маленькие наброски. Вот объяснение апстримом разницы между subtree и submodules: http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html#_comparing_em_subtree_em_merge_with_submodules
Created attachment 4195 [details] Вариант 1 Скрипт конвертирует submodule в subtree.
Created attachment 4196 [details] Вариант 2 Скрипт клонирует репозиторий и конвертирует ссылки на модули.
(В ответ на комментарий №51) > 1. Можно использовать "git merge -s subtree". Это поможет при клонировании, но > создаст общую историю между всеми репозиториями. Если общая история - не > проблема, то это лучший путь. git merge -s subtree вступают в неразрешимый конфликт при следующем обновлении upstream'ом ссылки на submodule. Этот вариант у меня не заработал.
Created attachment 4197 [details] Вариант 3 Скрипт располагает модули в бранчах родительского репозитория.
(В ответ на комментарий №54) > git merge -s subtree вступают в неразрешимый конфликт при следующем обновлении > upstream'ом ссылки на submodule. Конфликтов быть не должно. Расскажи как ты этого добился ?
(В ответ на комментарий №56) > (В ответ на комментарий №54) > > git merge -s subtree вступают в неразрешимый конфликт при следующем обновлении > > upstream'ом ссылки на submodule. > > Конфликтов быть не должно. Расскажи как ты этого добился ? Это было очень давно. Примерно так: - делаем как и ты с subtree - что-то там разрабатываем, дорабатываем, патчим, коммитим... - ждём пока upstream передвинет ссылку на новый коммит в submodule - мержим master с upstream, получаем бяку - submodule в upstream обновился, а у нас вместо него какое-то чудо в этом каталоге. Может быть, сейчас уже такого нет ?
(В ответ на комментарий №57) > Может быть, сейчас уже такого нет ? У меня subtree успешно работает в mozilla.org. Попробуй ещё. Должно работать.
Created attachment 4398 [details] gear-convert-submodule Вот более облагороженная утилита. Она позволяет конвертировать репозиторий с подмодулями (git-submodule) в репозиторий с бранчами (git-remote). При этом в конфиг репозитория прописываются соответствующие ремоты. Таким образом, история не смешивается, такую схему легко поддерживать и мерджить. Всех такой подход устроит ?
(In reply to comment #59) > Created an attachment (id=4398) [details] > gear-convert-submodule > > Вот более облагороженная утилита. Она позволяет конвертировать репозиторий с > подмодулями (git-submodule) в репозиторий с бранчами (git-remote). При этом в > конфиг репозитория прописываются соответствующие ремоты. Таким образом, история > не смешивается, такую схему легко поддерживать и мерджить. > > Всех такой подход устроит ? Правильно ли я понял, что предполагается применять эту утилиту только к специальному бранчу, на котором выпускаются релизы, а всю остальную работу выполнять в других бранчах? Как правильно обновлять этот специальный бранч?
(В ответ на комментарий №60) > Правильно ли я понял, что предполагается применять эту утилиту только к > специальному бранчу, на котором выпускаются релизы, а всю остальную работу > выполнять в других бранчах? Почти. Эта утилита нужна для единоразовой операции по конвертированию. Эта утилита прописывает ремоты на урлы, где расположены модули и втягивает их (репозитории, которые были подмодулями) как subtree. > Как правильно обновлять этот специальный бранч? $ git remote update foobar $ git merge -s subtree foobar/master
Думаю, что утилиту можно улучшить следующим образом: 1. Дать возможность задавать имя "специального бранча" через аргументы. 2. Дать возможность импортировать не только через ремоты, а через обычные бранчи тоже.
http://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=shortlog;h=refs/heads/gear-submodule > 1. Дать возможность задавать имя "специального бранча" через аргументы. Это не нужно т.к. утилита импортирует в текущий бранч. > 2. Дать возможность импортировать не только через ремоты, а через обычные > бранчи тоже. Это тоже не имеет смысла т.к. не ставится задача разработки модулей в основном бранче.
(In reply to comment #63) > http://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=shortlog;h=refs/heads/gear-submodule Не работает: $ git clone -q git://git.sv.gnu.org/sed $ cd sed $ gear-submodule init gear-submodule: Using 'heads/master' to import submodules gear-submodule: Converting 'gnulib' gear-submodule: gnulib: url not found HEAD is now at 9c56053 fix typo in the manual
(В ответ на комментарий №64) > Не работает: > $ git clone -q git://git.sv.gnu.org/sed > $ cd sed > $ gear-submodule init > gear-submodule: Using 'heads/master' to import submodules > gear-submodule: Converting 'gnulib' > gear-submodule: gnulib: url not found > HEAD is now at 9c56053 fix typo in the manual http://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=commitdiff;h=73a11916434ed3ee9b1f17e42b7c4ed4ca898f94 Забыл инициализацию модулей.
(In reply to comment #65) > Забыл инициализацию модулей. submodules можно и не инициализировать, работая с HEAD:.gitmodules напрямую. Но на практике "git submodule init" раньше или позже всё равно будет вызван в том бранче, где модули остаются модулями.
submodule.<name>.update Defines what to do when the submodule is updated by the superproject. If checkout (the default), the new commit specified in the superproject will be checked out in the submodule on a detached HEAD. If rebase, the current branch of the submodule will be rebased onto the commit specified in the superproject. If merge, the commit specified in the superproject will be merged into the current branch in the submodule. This config option is overridden if git submodule update is given the --merge or --rebase options.
Вот GHC после 7.8 ведёт разработку с submodules -- https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources (а до этого втечеие какого-то периода времени был самодельный аналог, т.е. исходники, нужные для сборки, не все входили непосредственно в дерево коммита -- https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources/Legacy ). Это к тому, что какой-никакой спрос на поддержку submodules в gear есть для сборки пакетов. Кажется, предложенная здесь утилита втягивает недостающие исходники из модулей в специальный бранч, который, наверное, может быть совмещён с бранчем, где spec и всё такое. Со стороны сборочницы пользование такой утилитой мейнтейнером не требует специальной поддержки? Т.е. можно пробовать. Обычно раньше можно было даже исходники не помещать в дерево бранча со спеком (делая git merge -s ours upstream) -- главное, чтобы нужные коммиты были среди предков коммита для сборки. Что, по-моему, было чем-то приятно: не надо смешивать исходники и спек в одном бранче. С этой утилитой конвертации такой приём уже больше не пройдёт (или потребует ещё одного бранча). По-моему, не очень серьёзная потеря... А ещё с ней не будет возможности в .gear/rules указать апстримный бранч или тэг как источник исходников, да? Надо будет ссылаться на самодельную ветку. Немного неприятно, потому что читается не так убедительно (раньше: вот, я беру чистые апстримные исходники и с ними работаю, это и записано в .gear/rules. А с конвертаций появляется ещё один уровень indirection и не очевидно, какие исходники берутся.)
Я немного подумал над этой проблемой. Если б я реализовывал, я бы склонялся к тому, чтобы научить gear рекурсивно вытаскивать поддеревья из модулей при сборке дерева -- при этом обычное требование из принципов gear: коммиты модулей должны быть доступны в том же репо (и как предки текущего коммита, что можно было бы достичь git merge -s ours module-tag в эту служебную ветку). Т.е. сближение с вариантом 3. Это потребует поддержки и на стороне сборочницы, если делать чисто. (Хотя можно обойти, нагородив преобразование модулей во много правил tar в .gear/rules + скрипт, который их будет распаковывать куда надо. А может, даже без скрипта можно, если .gear/rules умеет добавлять префикс к путям внутри tar.)
(В ответ на комментарий №69) > Я немного подумал над этой проблемой. Если б я реализовывал, я бы склонялся к > тому, чтобы научить gear рекурсивно вытаскивать поддеревья из модулей при > сборке дерева -- при этом обычное требование из принципов gear: коммиты модулей > должны быть доступны в том же репо (и как предки текущего коммита, что можно > было бы достичь git merge -s ours module-tag в эту служебную ветку). > > Т.е. сближение с вариантом 3. > > Это потребует поддержки и на стороне сборочницы, если делать чисто. (Хотя можно > обойти, нагородив преобразование модулей во много правил tar в .gear/rules + > скрипт, который их будет распаковывать куда надо. А может, даже без скрипта > можно, если .gear/rules умеет добавлять префикс к путям внутри tar.) А, умеет! base=base_name Add base_name as a leading path to all files in the generated archive. If this option is not specified, by default the archive name without the suffix (set by the name option) is used. Так что можно написать утилиту, которая будет переводить рекурсивно все модули в правила tar в .gear/rules и обновлять соотв.ссылки, а в .src.rpm будет куча архивов, которые надо будет просто друг за другом распаковать. Наверное, было бы удобно новый вид ссылки в gear ввести: помимо A name of a tag listed in the tag list specifies the root tree of the commit pointed to by the specified tag (directly or indirectly through a chain of tag objects). The specified commit must be an ancestor of the main commit, and all tag objects in the chain must be stored ещё и имя модуля внутри какого-то коммита. Достаточно, чтобы gear-store-tags новый вид ссылки понимал, и, кажется, тогда не нужно изменений на стороне сборочницы (тогда можно было бы сразу рекурсивный сбор дерева реализовать) -- я думал, как обойти это, оставаясь совместимым со старым gear.
(В ответ на комментарий №70) > ещё и имя модуля внутри какого-то коммита Тогда надо фиксировать конкретные коммиты в субмодулях по состоянию на какой-то момент времени (какой именно, если брать его автоматически, а не указывать всё множество коммитов руками?) -- не забываем, что одной из целей gear является воспроизводимость сборки.
(В ответ на комментарий №70) > Наверное, было бы удобно новый вид ссылки в gear ввести: помимо > > A name of a tag listed in the tag list specifies the > root tree of the commit pointed to by the specified tag > (directly or indirectly through a chain of tag objects). > The specified commit must be an ancestor of the main > commit, and all tag objects in the chain must be stored > > ещё и имя модуля внутри какого-то коммита. Достаточно, чтобы gear-store-tags > новый вид ссылки понимал, и, кажется, тогда не нужно изменений на стороне Подумал над форматом нового вида tree_path. Можно что-то вроде: upstream:modulepath1:. (в общем виде, upstream:modulepath1:path_in_tree) как рекурсивное расширение нынешнего подхода на вложенные модули. Здесь upstream:modulepath1 должно восприниматься как имя ссылки, которую сохранит улучшенный gear-store-tags. Но не будет ли двоеточие ломать старый gear, когда он его увидит?..
(В ответ на комментарий №71) > (В ответ на комментарий №70) > > ещё и имя модуля внутри какого-то коммита > Тогда надо фиксировать конкретные коммиты в субмодулях по состоянию на какой-то > момент времени (какой именно, если брать его автоматически, а не указывать всё > множество коммитов руками?) -- не забываем, что одной из целей gear является > воспроизводимость сборки. Ну да, конечно, аналогично gear-store-tags или как оно сейчас работает для ссылок на бранчи вроде upstream: tar: upstream:ghc name=@name@-@version@ (Не забываем gear-store-tags перед тем, как отправить на сборку.)
(В ответ на комментарий №73) > (В ответ на комментарий №71) > > (В ответ на комментарий №70) > > > ещё и имя модуля внутри какого-то коммита > > Тогда надо фиксировать конкретные коммиты в субмодулях по состоянию на какой-то > > момент времени (какой именно, если брать его автоматически, а не указывать всё Какой именно коммит субмодуля -- это зафиксировано с помощью git submodule внутри дерева коммита основной ветки. (В этом вроде как и фишка git submodule: воспроизводимость сборки с тем же самым коммитом субмодуля, стандартными средствами git. Тут если подумать, то задачи, решаемые git-submodule и gear пересекаются. Если писать gear с нуля сейчас, можно было бы рассмотреть реализацию на основе git-submodule, потому что возможности по фиксации коммита те же, что у gear-store-tags, и идея та же -- записать id коммита внутрь дерева основной ветки. У нас в файл .gear/tags/list, у них -- в дерево (директорию) в виде объекта особого типа, насколько я понимаю.) > > множество коммитов руками?) -- не забываем, что одной из целей gear является > > воспроизводимость сборки. > > Ну да, конечно, аналогично gear-store-tags или как оно сейчас работает для > ссылок на бранчи вроде upstream: > > tar: upstream:ghc name=@name@-@version@ > > > (Не забываем gear-store-tags перед тем, как отправить на сборку.)
(В ответ на комментарий №74) > Какой именно коммит субмодуля -- это зафиксировано с помощью git submodule > внутри дерева коммита основной ветки. (В этом вроде как и фишка git submodule: Политика gear требует наличия всех необходимых объектов (не ссылок на объекты как в случае с git submodule) без обращений к внешним источникам. См. https://bugzilla.altlinux.org/show_bug.cgi?id=17914#c20
(В ответ на комментарий №75) > Политика gear требует наличия всех необходимых объектов (не ссылок на объекты > как в случае с git submodule) без обращений к внешним источникам. > > См. https://bugzilla.altlinux.org/show_bug.cgi?id=17914#c20 Да, в этом разница. Я имел в виду общее: хранение ссылок на коммиты внутри коммитов, обновление и т.п.
Для истории: мне показалось, что submodules — это идущее в разрез со сборкой пакетов свойство, и реализовано нормально оно быть не может. Поэтому я добавил описание некоторой автоматизации объезда проблемы для тех апстримов, которые не выпускают тарболы или не умеют сделать их нормальными: https://www.altlinux.org/Сборка_пакета_с_git_submodule
Dear participants masculine, Have you made any progress on the issue? I am facing this problem right now: as the zpkglist library is transitioning into its beta stage, I need to attach to the git repo a few modules developed independently. I would love to use "git submodule", but then apparently I won't be able to build it with gear(1). I already faced this problem once with pkglist-unmets, and after a little while of biting my lips, I thought that merging in an unrelated history was not too cardinal a sin after all. https://github.com/svpv/pkglist-unmets/commit/638e3b6c So what should I do now? Is there any glimmer of hope? "Isle of hope, isle of tears" - can hear him sinning.
Продублирую тут написанное в https://lore.altlinux.org/devel/20220112165907.GA11057@altlinux.org/T/ Есть вариант решения, который можно посмотреть в https://git.altlinux.org/people/ldv/packages/?p=gear.git;a=shortlog;h=submodules Постановка задачи, которая привела к этому варианту решения, была примерно следующая: - в некотором проекте используются submodules для сравнительно небольших внешних подпроектов; - требуется собирать пакеты из этого проекта в Сизиф; - требуется не засорять историю этого проекта историями внешних подпроектов; - пользоваться этим должно быть не сложнее, чем gear-store-tags; - за всё это удобство можно заплатить увеличением размера git-репозитория проекта. В общих чертах реализация построена та том, что - есть новый инструмент gear-store-submodules, похожий на gear-store-tags, который превращает submodules в бандлы с помощью git-bundle(1), а эти бандлы, в свою очередь, добавляются в репозиторий как обычные файлы; - gear умеет автоматически конвертировать такие бандлы в архивы и добавлять такие архивы к основным архивам. Этот подход работает, но он подойдёт не всем.
Выглядит неплохо. Надо бы, конечно, пожить с этим в реальном использовании. А в чём минусы этого подхода с бандлами ?
(Ответ для Anton Farygin на комментарий #80) > Выглядит неплохо. Надо бы, конечно, пожить с этим в реальном использовании. > > А в чём минусы этого подхода с бандлами ? Репозиторий вырастает на размер бандлов. Если submodules у проекта много или же submodule сам по себе большой, то рост будет значительный.
а bundle занимает больше места, чем просто подшитая история с -s ours ? Мне почему-то казалось что это одно и тоже по объёму
В каждом бандле сохранена вся история подпроекта до указанного коммита, поэтому со временем в git-репозитории будет квадратичный рост размера подпроекта.
(Ответ для Anton Farygin на комментарий #82) > а bundle занимает больше места, чем просто подшитая история с -s ours ? > > Мне почему-то казалось что это одно и тоже по объёму Насколько я помню ты прав. Но я говорил немного не об этом. bundle это pack с историей, которая занимает место. Это больше чем git-archive.
Для каждой новой версии делается и подшивается новый бандл, содержащий всю историю проекта за всё время ? Нет, это конечно будет адски много. Можно подсчитать если интересно, но мне кажется что в каких-то проектах это фактически будет невозможно использовать. Особенно в тех, кто выпускает новую версию по крону один раз в неделю.
(Ответ для Anton Farygin на комментарий #85) > Для каждой новой версии делается и подшивается новый бандл, содержащий всю > историю проекта за всё время ? > Нет, это конечно будет адски много. Можно подсчитать если интересно, но мне > кажется что в каких-то проектах это фактически будет невозможно > использовать. Особенно в тех, кто выпускает новую версию по крону один раз в > неделю. Данная реализация сохраняет и восстанавливает ровно то же состояние, которое ты получаешь в репозитории после git submodules --init Соответственно размер соответствующий.
Да, но это состояние, в отличии от git submodules init, если я правильно понял Диму, для каждой новой версии сохраняется заново. Т.е. - если репозиторий содержит 20 submodules, каждый из которых по 100 мегабайт, то при сборке каждой новой версии основной репозиторий будет расти примерно на 2000 мегабайт, т.к. состояние каждого сабмодуля подкладывается большим бинарём.
Антон, мне тут пришла мысль делать bundle c --depth=1. Это может помочь ? https://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=shortlog;h=refs/heads/submodules
Кстати да, возможно. Надо попробовать.
(In reply to Anton Farygin from comment #89) > Кстати да, возможно. Надо попробовать. с --depth=1 у меня bundle получился меньше и остальные операции вроде не жаловались на нехватку объектов. Попробуй бранч по ссылке.
Необходимо добавить поддержку bundle в gear. Использую в пакете: http://git.altlinux.org/people/ved/packages/libmaplibre-native.git Реализацию взял из этого бранча: https://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=shortlog;h=refs/heads/submodules
У меня время не дошло попробовать, да и я пока-что больше настроен на другую схему, она мне удобнее, т.к. видно историю каждого сабмодуля.
