* [devel] gear-rules and submodules @ 2008-12-07 16:06 Led 2008-12-07 16:49 ` Sergey Vlasov 0 siblings, 1 reply; 9+ messages in thread From: Led @ 2008-12-07 16:06 UTC (permalink / raw) To: ALT Linux Team development discussions Что нужно написать в .gear-rules, чтобы в тарболл попали каталоги содержимым, которые являются с точки зрения git submodule'ями? -- Led ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] gear-rules and submodules 2008-12-07 16:06 [devel] gear-rules and submodules Led @ 2008-12-07 16:49 ` Sergey Vlasov 2008-12-07 17:03 ` Led 0 siblings, 1 reply; 9+ messages in thread From: Sergey Vlasov @ 2008-12-07 16:49 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 1453 bytes --] On Sun, Dec 07, 2008 at 06:06:56PM +0200, Led wrote: > Что нужно написать в .gear-rules, чтобы в тарболл попали каталоги содержимым, > которые являются с точки зрения git submodule'ями? В принципе в текущей версии gear получается запаковать подобный субмодуль целиком в отдельный тарболл (а вот подкаталог субмодуля запаковать уже не получится). Однако подобные операции не вполне соответствуют принципам построения gear. Изначально предполагалось, что для сборки определённой версии пакета из репозитория с помощью gear достаточно получить только объекты, на которые ссылается требуемый коммит (именно отсюда вытекает ограничение на ссылки, проставляемые через gear-create-tag). Но ссылки на субмодули в git, в отличие от других ссылок, не требуют обязательного присутствия указанного объекта в репозитории; таким образом, если выполнить git fetch $repo $tag в пустой репозиторий, а затем вызвать gear -t $tag, при использовании субмодулей соответствующие объекты не будут найдены, поскольку git fetch их не получает. Таким образом, для применения субмодулей в репозиториях, с которыми будет использоваться gear, необходимо добавить какие-то дополнительные требования к содержимому этих репозиториев (скорее всего, придётся потребовать, чтобы все используемые субмодули также содержались в этом репозитории), а также документировать способ, позволяющий по указанному тегу получить набор объектов, достаточный для сборки. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] gear-rules and submodules 2008-12-07 16:49 ` Sergey Vlasov @ 2008-12-07 17:03 ` Led 2008-12-07 17:58 ` Kirill A. Shutemov 0 siblings, 1 reply; 9+ messages in thread From: Led @ 2008-12-07 17:03 UTC (permalink / raw) To: devel On Sunday, 07 December 2008 18:49:17 Sergey Vlasov wrote: > On Sun, Dec 07, 2008 at 06:06:56PM +0200, Led wrote: > > Что нужно написать в .gear-rules, чтобы в тарболл попали каталоги > > содержимым, которые являются с точки зрения git submodule'ями? > > В принципе в текущей версии gear получается запаковать подобный > субмодуль целиком в отдельный тарболл (а вот подкаталог субмодуля > запаковать уже не получится). Однако подобные операции не вполне > соответствуют принципам построения gear. > > Изначально предполагалось, что для сборки определённой версии пакета > из репозитория с помощью gear достаточно получить только объекты, на > которые ссылается требуемый коммит (именно отсюда вытекает ограничение > на ссылки, проставляемые через gear-create-tag). Но ссылки на > субмодули в git, в отличие от других ссылок, не требуют обязательного > присутствия указанного объекта в репозитории; таким образом, если > выполнить git fetch $repo $tag в пустой репозиторий, а затем вызвать > gear -t $tag, при использовании субмодулей соответствующие объекты не > будут найдены, поскольку git fetch их не получает. > > Таким образом, для применения субмодулей в репозиториях, с которыми > будет использоваться gear, необходимо добавить какие-то дополнительные > требования к содержимому этих репозиториев (скорее всего, придётся > потребовать, чтобы все используемые субмодули также содержались в этом > репозитории), Так оно и есть. В частности, содержимое ./m4/ - субмодуль и без него, естественно, пакет не собирается. Может имеет смысл для сборки оформить эти субмодули как отдельные бранчи и перед сборкой gear'ом мерджить основной upstream-бранч и эти бранчи субмодулей в другой бранч (кстати, как его лучше назвать? и какой метой мерджа задействовать?)? > а также документировать способ, позволяющий по > указанному тегу получить набор объектов, достаточный для сборки. -- Led ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] gear-rules and submodules 2008-12-07 17:03 ` Led @ 2008-12-07 17:58 ` Kirill A. Shutemov 2008-12-08 1:12 ` Led 0 siblings, 1 reply; 9+ messages in thread From: Kirill A. Shutemov @ 2008-12-07 17:58 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 3255 bytes --] On Sun, Dec 07, 2008 at 07:03:10PM +0200, Led wrote: > On Sunday, 07 December 2008 18:49:17 Sergey Vlasov wrote: > > On Sun, Dec 07, 2008 at 06:06:56PM +0200, Led wrote: > > > Что нужно написать в .gear-rules, чтобы в тарболл попали каталоги > > > содержимым, которые являются с точки зрения git submodule'ями? > > > > В принципе в текущей версии gear получается запаковать подобный > > субмодуль целиком в отдельный тарболл (а вот подкаталог субмодуля > > запаковать уже не получится). Однако подобные операции не вполне > > соответствуют принципам построения gear. > > > > Изначально предполагалось, что для сборки определённой версии пакета > > из репозитория с помощью gear достаточно получить только объекты, на > > которые ссылается требуемый коммит (именно отсюда вытекает ограничение > > на ссылки, проставляемые через gear-create-tag). Но ссылки на > > субмодули в git, в отличие от других ссылок, не требуют обязательного > > присутствия указанного объекта в репозитории; таким образом, если > > выполнить git fetch $repo $tag в пустой репозиторий, а затем вызвать > > gear -t $tag, при использовании субмодулей соответствующие объекты не > > будут найдены, поскольку git fetch их не получает. > > > > Таким образом, для применения субмодулей в репозиториях, с которыми > > будет использоваться gear, необходимо добавить какие-то дополнительные > > требования к содержимому этих репозиториев (скорее всего, придётся > > потребовать, чтобы все используемые субмодули также содержались в этом > > репозитории), > > Так оно и есть. В частности, содержимое ./m4/ - субмодуль и без него, > естественно, пакет не собирается. Может имеет смысл для сборки оформить эти > субмодули как отдельные бранчи и перед сборкой gear'ом мерджить основной > upstream-бранч и эти бранчи субмодулей в другой бранч (кстати, как его лучше > назвать? и какой метой мерджа задействовать?)? -s subtree. -- Regards, Kirill A. Shutemov + Belarus, Minsk + ALT Linux Team, http://www.altlinux.org/ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] gear-rules and submodules 2008-12-07 17:58 ` Kirill A. Shutemov @ 2008-12-08 1:12 ` Led 2008-12-08 6:19 ` Kirill A. Shutemov 0 siblings, 1 reply; 9+ messages in thread From: Led @ 2008-12-08 1:12 UTC (permalink / raw) To: ALT Linux Team development discussions On Sunday, 07 December 2008 19:58:42 Kirill A. Shutemov wrote: > On Sun, Dec 07, 2008 at 07:03:10PM +0200, Led wrote: > > On Sunday, 07 December 2008 18:49:17 Sergey Vlasov wrote: > > > On Sun, Dec 07, 2008 at 06:06:56PM +0200, Led wrote: > > > > Что нужно написать в .gear-rules, чтобы в тарболл попали каталоги > > > > содержимым, которые являются с точки зрения git submodule'ями? > > > > > > В принципе в текущей версии gear получается запаковать подобный > > > субмодуль целиком в отдельный тарболл (а вот подкаталог субмодуля > > > запаковать уже не получится). Однако подобные операции не вполне > > > соответствуют принципам построения gear. > > > > > > Изначально предполагалось, что для сборки определённой версии пакета > > > из репозитория с помощью gear достаточно получить только объекты, на > > > которые ссылается требуемый коммит (именно отсюда вытекает ограничение > > > на ссылки, проставляемые через gear-create-tag). Но ссылки на > > > субмодули в git, в отличие от других ссылок, не требуют обязательного > > > присутствия указанного объекта в репозитории; таким образом, если > > > выполнить git fetch $repo $tag в пустой репозиторий, а затем вызвать > > > gear -t $tag, при использовании субмодулей соответствующие объекты не > > > будут найдены, поскольку git fetch их не получает. > > > > > > Таким образом, для применения субмодулей в репозиториях, с которыми > > > будет использоваться gear, необходимо добавить какие-то дополнительные > > > требования к содержимому этих репозиториев (скорее всего, придётся > > > потребовать, чтобы все используемые субмодули также содержались в этом > > > репозитории), > > > > Так оно и есть. В частности, содержимое ./m4/ - субмодуль и без него, > > естественно, пакет не собирается. Может имеет смысл для сборки оформить > > эти субмодули как отдельные бранчи и перед сборкой gear'ом мерджить > > основной upstream-бранч и эти бранчи субмодулей в другой бранч (кстати, > > как его лучше назвать? и какой метой мерджа задействовать?)? > > -s subtree. Например? Как указать каталог, в который нужно мерджить? -- Led ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] gear-rules and submodules 2008-12-08 1:12 ` Led @ 2008-12-08 6:19 ` Kirill A. Shutemov 2008-12-08 8:49 ` Led 0 siblings, 1 reply; 9+ messages in thread From: Kirill A. Shutemov @ 2008-12-08 6:19 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 3697 bytes --] On Mon, Dec 08, 2008 at 03:12:02AM +0200, Led wrote: > On Sunday, 07 December 2008 19:58:42 Kirill A. Shutemov wrote: > > On Sun, Dec 07, 2008 at 07:03:10PM +0200, Led wrote: > > > On Sunday, 07 December 2008 18:49:17 Sergey Vlasov wrote: > > > > On Sun, Dec 07, 2008 at 06:06:56PM +0200, Led wrote: > > > > > Что нужно написать в .gear-rules, чтобы в тарболл попали каталоги > > > > > содержимым, которые являются с точки зрения git submodule'ями? > > > > > > > > В принципе в текущей версии gear получается запаковать подобный > > > > субмодуль целиком в отдельный тарболл (а вот подкаталог субмодуля > > > > запаковать уже не получится). Однако подобные операции не вполне > > > > соответствуют принципам построения gear. > > > > > > > > Изначально предполагалось, что для сборки определённой версии пакета > > > > из репозитория с помощью gear достаточно получить только объекты, на > > > > которые ссылается требуемый коммит (именно отсюда вытекает ограничение > > > > на ссылки, проставляемые через gear-create-tag). Но ссылки на > > > > субмодули в git, в отличие от других ссылок, не требуют обязательного > > > > присутствия указанного объекта в репозитории; таким образом, если > > > > выполнить git fetch $repo $tag в пустой репозиторий, а затем вызвать > > > > gear -t $tag, при использовании субмодулей соответствующие объекты не > > > > будут найдены, поскольку git fetch их не получает. > > > > > > > > Таким образом, для применения субмодулей в репозиториях, с которыми > > > > будет использоваться gear, необходимо добавить какие-то дополнительные > > > > требования к содержимому этих репозиториев (скорее всего, придётся > > > > потребовать, чтобы все используемые субмодули также содержались в этом > > > > репозитории), > > > > > > Так оно и есть. В частности, содержимое ./m4/ - субмодуль и без него, > > > естественно, пакет не собирается. Может имеет смысл для сборки оформить > > > эти субмодули как отдельные бранчи и перед сборкой gear'ом мерджить > > > основной upstream-бранч и эти бранчи субмодулей в другой бранч (кстати, > > > как его лучше назвать? и какой метой мерджа задействовать?)? > > > > -s subtree. > > Например? Как указать каталог, в который нужно мерджить? http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html -- Regards, Kirill A. Shutemov + Belarus, Minsk + ALT Linux Team, http://www.altlinux.org/ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] gear-rules and submodules 2008-12-08 6:19 ` Kirill A. Shutemov @ 2008-12-08 8:49 ` Led 2008-12-08 10:28 ` Sergey Vlasov 0 siblings, 1 reply; 9+ messages in thread From: Led @ 2008-12-08 8:49 UTC (permalink / raw) To: ALT Linux Team development discussions On Monday, 08 December 2008 08:19:57 Kirill A. Shutemov wrote: > On Mon, Dec 08, 2008 at 03:12:02AM +0200, Led wrote: > > On Sunday, 07 December 2008 19:58:42 Kirill A. Shutemov wrote: > > > On Sun, Dec 07, 2008 at 07:03:10PM +0200, Led wrote: > > > > On Sunday, 07 December 2008 18:49:17 Sergey Vlasov wrote: > > > > > On Sun, Dec 07, 2008 at 06:06:56PM +0200, Led wrote: > > > > > > Что нужно написать в .gear-rules, чтобы в тарболл попали каталоги > > > > > > содержимым, которые являются с точки зрения git submodule'ями? > > > > > > > > > > В принципе в текущей версии gear получается запаковать подобный > > > > > субмодуль целиком в отдельный тарболл (а вот подкаталог субмодуля > > > > > запаковать уже не получится). Однако подобные операции не вполне > > > > > соответствуют принципам построения gear. > > > > > > > > > > Изначально предполагалось, что для сборки определённой версии > > > > > пакета из репозитория с помощью gear достаточно получить только > > > > > объекты, на которые ссылается требуемый коммит (именно отсюда > > > > > вытекает ограничение на ссылки, проставляемые через > > > > > gear-create-tag). Но ссылки на субмодули в git, в отличие от > > > > > других ссылок, не требуют обязательного присутствия указанного > > > > > объекта в репозитории; таким образом, если выполнить git fetch > > > > > $repo $tag в пустой репозиторий, а затем вызвать gear -t $tag, при > > > > > использовании субмодулей соответствующие объекты не будут найдены, > > > > > поскольку git fetch их не получает. > > > > > > > > > > Таким образом, для применения субмодулей в репозиториях, с которыми > > > > > будет использоваться gear, необходимо добавить какие-то > > > > > дополнительные требования к содержимому этих репозиториев (скорее > > > > > всего, придётся потребовать, чтобы все используемые субмодули также > > > > > содержались в этом репозитории), > > > > > > > > Так оно и есть. В частности, содержимое ./m4/ - субмодуль и без него, > > > > естественно, пакет не собирается. Может имеет смысл для сборки > > > > оформить эти субмодули как отдельные бранчи и перед сборкой gear'ом > > > > мерджить основной upstream-бранч и эти бранчи субмодулей в другой > > > > бранч (кстати, как его лучше назвать? и какой метой мерджа > > > > задействовать?)? > > > > > > -s subtree. > > > > Например? Как указать каталог, в который нужно мерджить? > > http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.h >tml Спасибо! Но, как вижу, без read-tree всё же не обойтись - это я как раз нашёл:) А про заключительный "git pull -s subtree" не знал. Сейчас попробую. P.S. А merge всё таки с "-s ours", а не "-s subtree":) -- Led ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] gear-rules and submodules 2008-12-08 8:49 ` Led @ 2008-12-08 10:28 ` Sergey Vlasov 2008-12-08 11:26 ` Led 0 siblings, 1 reply; 9+ messages in thread From: Sergey Vlasov @ 2008-12-08 10:28 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 610 bytes --] On Mon, Dec 08, 2008 at 10:49:13AM +0200, Led wrote: [...] > > > > -s subtree. > > > > > > Например? Как указать каталог, в который нужно мерджить? > > > > http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.h > >tml > > Спасибо! Но, как вижу, без read-tree всё же не обойтись - это я как раз > нашёл:) > А про заключительный "git pull -s subtree" не знал. Сейчас попробую. > > P.S. А merge всё таки с "-s ours", а не "-s subtree":) Первый раз делается merge --no-commit -s ours, потом фокусы с read-tree. При последующих обновлениях достаточно git merge -s subtree. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] gear-rules and submodules 2008-12-08 10:28 ` Sergey Vlasov @ 2008-12-08 11:26 ` Led 0 siblings, 0 replies; 9+ messages in thread From: Led @ 2008-12-08 11:26 UTC (permalink / raw) To: devel On Monday, 08 December 2008 12:28:34 Sergey Vlasov wrote: > On Mon, Dec 08, 2008 at 10:49:13AM +0200, Led wrote: > [...] > > > > > > -s subtree. > > > > > > > > Например? Как указать каталог, в который нужно мерджить? > > > > > > http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtr > > >ee.h tml > > > > Спасибо! Но, как вижу, без read-tree всё же не обойтись - это я как раз > > нашёл:) > > А про заключительный "git pull -s subtree" не знал. Сейчас попробую. > > > > P.S. А merge всё таки с "-s ours", а не "-s subtree":) > > Первый раз делается merge --no-commit -s ours, потом фокусы с read-tree. > При последующих обновлениях достаточно git merge -s subtree. Вроде целостная картина складывается... Спасибо! -- Led ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-12-08 11:26 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-12-07 16:06 [devel] gear-rules and submodules Led 2008-12-07 16:49 ` Sergey Vlasov 2008-12-07 17:03 ` Led 2008-12-07 17:58 ` Kirill A. Shutemov 2008-12-08 1:12 ` Led 2008-12-08 6:19 ` Kirill A. Shutemov 2008-12-08 8:49 ` Led 2008-12-08 10:28 ` Sergey Vlasov 2008-12-08 11:26 ` Led
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git