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

[Sergey Vlasov]

On Tue, Sep 26, 2006 at 05:01:36PM +0400, Alex V. Myltsev wrote:
> On Tue, 26 Sep 2006 15:49:04 +0400
> Sergey Vlasov wrote:
> 
> > branch1 - это имя, которое gear-release в момент запуска преобразует в
> > sha1?  В таком случае, даже если .gear-tags лежит в репозитории, это
> > само по себе ничего не значит, так как неизвестно, на что указывала
> > ссылка с указанным именем в момент запуска gear-release,
> > следовательно, действия мантейнера невозможно повторить
> > ...  Разве что модифицировать .gear-tags в этом дереве, добавив туда
> > реально использованные sha1 пришитых бранчей.
> Ну ситуация же не становится лучше, если sha1 хранить в .gear-tags или
> ещё где-то. Всё равно непонятно, откуда эти sha1 появились.

Если в .gear-tags хранится sha1 коммита, у этого коммита есть какая-то
история.  Понятно, что можно закоммитить неизвестно откуда взятые файлы с
бесполезным сообщением и заведомо ложной информацией об авторе, но эту
проблему вряд ли можно решить техническими средствами.

Если имеется только sha1 от дерева, действительно непонятно, откуда оно
появилось.

> Я предлагаю хранить sha1 прямо в деревьях, родными механизмами git.

sha1 каких объектов - tree или commit?  Для нормальной работы нужен
commit; искать commit по tree никуда не годится.

> > > * Создаёт новый коммит1, который ссылается на новосозданное дерево,
> > > а родителем числит прошлый release commit. Создаёт новый коммит2,
> > >   который ссылается на новосозданное дерево, но не имеет родителей.
> > Откуда берётся прошлый release commit?
> Хм. Они вроде все лежат в refs/releases/?

И какой из них последний?

> > У коммит1, если уж делать его в таком виде, нужно вторым родителем
> > ставить текущий коммит
> Нет, родителем у него должен быть только прошлый release commit.

Так делать нельзя.  Тот коммит, который идёт на сборку, должен иметь
ссылки на полную историю пакета, и этой истории должно быть достаточно для
нормального продолжения работы над пакетом (возможно, совершенно другим
мантейнером).  Если release commit будет содержать только склеенное дерево
исходников без явных ссылок на те коммиты, из которых это дерево было
собрано, продолжить работу на базе этого коммита будет проблематично (при
отсутствии явных ссылок рабочий коммит, из которого делался релиз, не
попадёт в кэширующий репозиторий Сизифа, а останется только в персональном
репозитории мантейнера, и вполне может оттуда пропасть).

> Тогда дифф между релизами будет настоящим диффом, со всеми исходниками.

git-diff release^1 release выдаст этот дифф независимо от того, есть у
коммита ещё родители или нет.  Вот в gitk, если явно не запросить,
получится diff --cc.

> А вот информацию о всех сшитых вместе коммитах надо где-то хранить в
> релизе, это правда. Иначе нельзя будет проверить наследственность.

Проверять наследственность для сшитых коммитов, вероятно, как раз не
нужно, поскольку мантейнер вполне может в очередном релизе что-то
выбросить, и не стоит заставлять его в таком случае делать fake merge.
Вполне достаточно, чтобы release commit происходил от аналогичного коммита
предыдущего релиза.

Хотя при такой схеме, которая описана здесь, получается, что надо
проверять наследственность не только для release commit, но и для рабочего
коммита, из которого делается релиз (иначе можно не глядя пришить к
предыдущему релизу что попало).

> > > если .gear-tags непуст, то gear не найдёт в нём path* и отвалится.
> > >   Это напоминание сборщику, что HEAD требует применения
> > > gear-release.
> > Это неудобно - как минимум, нужен wrapper, позволяющий вызвать gear
> > одной командой (либо поддержка в самом gear).
> Поддержка в самом gear должна отсутствовать по определению. Из этого
> commit-ish не собирается однозначно пакет; значит, gear на него
> применять нельзя.

Либо нужно использовать схему, при которой пакет собирается однозначно.

> Wrapper можно сделать, но он, разумеется, не будет обеспечивать
> воспроизводимости.
>  
> > это должен быть не gear-release, а что-то другое.
> ОК.

Как минимум, подписывать каждую тестовую сборку - это перебор.

> > при отсутствии связей между коммитами все объекты всегда передаются
> > полностью
> Беда. Я надеялся, что если дерево уже есть, то его заново не передают.
> Тогда, конечно, bare отпадает.

Протокол git определяет только общие коммиты, получение списка нужных
tree/blob происходит уже на более поздней стадии, до которой при
отсутствии общих коммитов нужная информация уже не доходит.

> > Кроме того, имея подобный коммит, никак не связанный с остальной
> > историей, невозможно получить изменения исходников относительно
> > оригинальной версии
> Ну, это и сейчас, с историей, непонятно как делать. Где она,
> оригинальная версия?

При наличии истории есть хотя бы какая-то возможность что-то найти.  При
отсутствии нормальных связей до истории можно просто не добраться.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20060926/6af24312/attachment-0001.bin>