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

[Sergey Vlasov]

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).
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20060930/7da1fe54/attachment-0001.bin>