Re: [devel] gear -- создание тарбола из другого branch

[Sergey Vlasov <vsu@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

On Sat, Sep 23, 2006 at 06:07:47PM +0400, Dmitry V. Levin wrote:
> On Sat, Sep 23, 2006 at 01:19:57PM +0400, Денис Смирнов wrote:
> > On Sat, Sep 23, 2006 at 12:48:25PM +0400, Dmitry V. Levin wrote:
> > 
> > >> Можно, конечно, попробовать указывать прямо ссылку на конкретный объект.
> > DVL> Можно было бы указывать sha1-имя, но этим не очень удобно было бы
> > DVL> пользоваться.

Либо завести рядом с .gear-rules файл .gear-tags, в который класть
записи вида "sha1 name", и при разборе .gear-rules использовать только
имена из этого файла.  Причём, кроме этих имён в чистом виде, хорошо
бы разрешить и конструкции вида treeish:some/path (а, возможно, и
ссылки на родительские коммиты через ^ и ~ - правда, на них можно
повлиять через .git/info/grafts).

> > Только вот есть ли гарантия, что объект на который ссылаемся не будет по
> > какой-либо причине в будушем удален?
> 
> К сожалению, гарантии нет, что сводит всю идею на нет.

Можно держать .gear-rules и spec в отдельном бранче, куда фиктивно
(через git-pull -s ours) мержить бранчи, содержащие реальные
исходники; тогда гарантировать наличие нужных объектов будет связь
между коммитами.

В этом случае неплохо было бы, чтобы gear проверял наличие этой связи;
тогда придётся в параметре опции -t требовать не просто treeish, а
commitish[:path].

> > То бишь в tar будет и spec с .gear-rules, так?
> > 
> > Хотя, наверное, это не шибко страшно, хотя и очень некрасиво.
> 
> Некрасиво?  Почему?  Кто на этот tar будет смотреть?

А когда у нас по плану уничтожение src.rpm?  Пока это не произойдёт,
смотреть на tar придётся.  И мне не нравится, что сейчас этот tar
может содержать непонятно что вместо оригинальных исходников.

> > Вот git-svn скачивает 3 репозитория. Их надо раскладывать по разным
> > каталогам. В них есть одинаковые имена (configure, например|. Я и ручками
> > после git pull из них трех не разберусь, как это сделать скриптом?
> 
> Да, с подкаталогами было бы удобнее.

Теоретически можно было бы написать собственную стратегию для merge,
но тогда надо как-то передавать ей параметры, а нормальных средств для
этого не предусмотрено (разве что SOME_VAR=... git-pull -s my ...).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]