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

[Dmitry V. Levin]

On Sat, Sep 30, 2006 at 11:30:55PM +0400, Sergey Vlasov wrote:
> On Tue, Sep 26, 2006 at 11:01:02PM +0400, Sergey Vlasov wrote:
> > On Sat, Sep 23, 2006 at 11:28:11PM +0400, Dmitry V. Levin wrote:
> > > On Sat, Sep 23, 2006 at 08:51:45PM +0400, Sergey Vlasov wrote:
> > > > On Sat, Sep 23, 2006 at 07:54:46PM +0400, Dmitry V. Levin wrote:
> > > > > On Sat, Sep 23, 2006 at 07:23:46PM +0400, Sergey Vlasov wrote:
> > > > [...]
> > > > > > Можно держать .gear-rules и spec в отдельном бранче, куда фиктивно
> > > > > > (через git-pull -s ours) мержить бранчи, содержащие реальные
> > > > > > исходники; тогда гарантировать наличие нужных объектов будет связь
> > > > > > между коммитами.
> > > [...]
> > > > Только получается, что в .gear-tags придётся писать ссылки именно на
> > > > commit - ссылку на объект типа tag написать уже нельзя.
> > > 
> > > Жаль.  Хотя какая разница, если там всё равно будут sha1-имена.
> > 
> > На самом деле, если подумать, можно сделать и ссылку на tag.
> > 
> > Действительно, в объект типа commit или tree нельзя непосредственно
> > положить ссылку на объект типа tag.  Но никто не может запретить
> > прочитать содержимое объекта типа tag и положить его в объект типа
> > blob.  Таким образом, можно сделать .gear-tags не файлом, а каталогом,
> > куда складывать копии тегов.
> > 
> > Если ссылка указывала напрямую на commit, можно класть туда просто
> > sha1 (его всегда можно отличить от содержимого объекта tag).  Цепочку
> > объектов tag тоже можно сохранить - например, поместив второй и
> > последующие теги в цепочке под именами вида @<sha1> (символ '@' в
> > именах ссылок встречаться не может).
> 
> Похоже, проще оказывается складывать файлы с сохранённым содержимым
> тегов не под оригинальными именами, а с именем, соответствующим их
> sha1, и помещать имена в файл .gear-tags/list (иначе пришлось бы
> возиться с каталогами внутри .gear-tags).

Если это будет не очень сложно, то можно сделать.
У кого-нибудь ещё есть мнения на эту тему?

> В этом случае, если upstream также ведёт разработку с использованием
> git, в release commit будут сохранены оригинальные теги (с подписями
> GPG, если они там были).  Правда, на работу git-tar-tree это не влияет
> (ссылка на тег всё равно сводится к commit даже в заголовке архива).
> 
> > При сборке можно создать во временном каталоге репозиторий, записать в
> > .git/objects/info/alternates текущее значение $GIT_DIR, после чего
> > перенаправить GIT_DIR во временный репозиторий и восстановить там
> > сохранённые объекты тегов через git-hash-object.
> 
> Это в принципе работает (только подменять надо не GIT_DIR, а
> GIT_OBJECT_DIRECTORY, чтобы не нужно было копировать .git/refs).
> Правда, появляется ограничение - значение GIT_DIR не может содержать
> символ '\n' (поскольку такой каталог невозможно записать в
> objects/info/alternates).

Я думаю, что это ограничение несущественно.


-- 
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20061004/cb417fa7/attachment-0001.bin>