[devel] git submodules vs gear
Dmitry V. Levin
ldv на altlinux.org
Вс Янв 10 19:59:44 UTC 2010
On Sun, Jan 10, 2010 at 07:46:41PM +0200, Michael Shigorin wrote:
> On Sun, Jan 10, 2010 at 01:31:25AM +0300, Dmitry V. Levin wrote:
> > Now imagine that this commit id uses submodules and required external
> > commit objects are missing, because no git repository that uses
> > submodules is required to be self-contained. In this case, gear would
> > have to attempt to fetch these commits from internet. This is NOT
> > reliable, and gear would not be able to guarantee reproducibly.
>
> Цитируя https://bugzilla.altlinux.org/show_bug.cgi?id=17914#c24:
> > Привнесение поддержки submodule не должно сломать эту гарантию.
>
> Не можешь дать гарантию -- не давай.
Мне нужно, чтобы пакет воспроизводимо собирался на изолированном от
внешнего мира сервере. Если инструмент не даёт мне такой гарантии,
то мне такой инструмент не нужен.
> Особенно если опираешься на
> услуги посредников. git когда-то давно мог гарантировать _полную_
> историю, а потом появились shallow clones и submodules (причём не
> от прихоти или "разработки ради разработки") и эта гарантия стала
> ограниченной. Собственно, что legion@ и говорит в #c45.
shallow clones и submodules не нарушают главного свойства git -- гарантии
неизменности истории. А то, что часть коммитов может быть оформлена таким
образом, чтобы снять обязательность локального размещения -- это не меняет
сути дела для git. Всё таки надо понимать, что у git и gear разные
задачи.
> Цитируя #c26 и #c34:
> > Нарушается принцип достаточности коммита.
>
> Ну и что? Не можешь решить проблему за человека -- не мешай ему
> самому решать их, создавая непреодолимые. "Не навреди".
>
> А ключевые принципы, на которые опираются hasher, gear и подобные
> инструменты -- неплохо было б описывать в их документации.
Я стараюсь в меру своих сил и возможностей.
> Пока что отсутствие поддержки git submodule в сизифном gear
> противоречит его же документированной идее ("собирать пакеты
> из произвольно устроенного git-репозитория") и описанным
> ограничениям, накладываемым на структуру репозитория.
Когда был написан этот текст, git submodule не было даже в проекте.
Очевидно, текст требуется актуализировать.
> При этом упомянутый тобой принцип в ABOUT.ru.utf8 не описан --
> вскользь проскакивает во фразе "согласно которым производится
> экспорт из коммита репозитория (в форму, из которой можно
> однозначно изготовить srpm-пакет или запустить сборку)" разве.
>
> То есть твоя позиция нарушает явно сформулированный принцип,
> даже если, как выясняется в баге с патчем, опирается на другой
> -- нигде не опубликованный до обсуждения в баге, как понимаю.
Очевидно, формулировки пора обновить, чтобы они лучше отражали реальную
картину.
> > As you see, there is a fundamental problem: GIT submodule breaks
> > repository completeness, but gear requires git repositories to be
> > self-contained. I have no idea how to avoid this problem.
>
> Исправить ожидания gear на соответствующие наблюдаемой
> действительности, разумеется.
Повторю ещё раз: мне нужно, чтобы gear решал вполне простую и понятную
задачу (я написал выше, какую).
>
> Возможно, обязав заливать используемые для субмодулей репо на
> git.alt
Это не представляется возможным.
> и указывать соответствие где-нить в .gear/submodules
> во избежание тупой автоматической траты времени и трафика.
>
> При этом технический мерж можно делать прямо перед скручиванием
> тарбола, как понимаю. И репо чистые, и Дима доволен.
Сборочный тэг должен указывать на коммит, замыкание которого находится
в репозитории целиком и передаётся базовыми операциями (git fetch и
git push) без потерь. Всё остальное -- детали реализации.
--
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : отсутствует
Тип : application/pgp-signature
Размер : 198 байтов
Описание: отсутствует
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20100110/bee05a7a/attachment.bin>
Подробная информация о списке рассылки Devel