From: Sergey Vlasov <vsu@altlinux.ru> To: devel@lists.altlinux.org Subject: Re: [devel] gear -- создание тарбола из другого branch Date: Tue, 26 Sep 2006 15:49:04 +0400 Message-ID: <20060926114904.GE18551@master.mivlgu.local> (raw) In-Reply-To: <20060926141425.5647173a@localhost.localdomain> [-- Attachment #1: Type: text/plain, Size: 5038 bytes --] On Tue, Sep 26, 2006 at 02:14:25PM +0400, Alex V. Myltsev wrote: > У меня есть такое представление о том, как должен работать gear-release: > > * Читает .gear-tags, в котором написано: > branch1 path1 > branch2 path2 branch1 - это имя, которое gear-release в момент запуска преобразует в sha1? В таком случае, даже если .gear-tags лежит в репозитории, это само по себе ничего не значит, так как неизвестно, на что указывала ссылка с указанным именем в момент запуска gear-release, следовательно, действия мантейнера невозможно повторить (разве что попытаться найти, куда показывала ссылка, по совпадению tree id, но в этом случае однозначный результат не гарантируется)... > ... > * Из каждого бранча извлекает tree id посредством git-rev-parse и > git-cat-file. > * Создаёт новое дерево следующим путём: > { > git-ls-tree HEAD > for (tree, path) in .gear-tags: > echo "040000 tree $tree $path" > } >git-mktree > То есть пришивает к текущему дереву деревья из нужных бранчей под > нужными именами. ... Разве что модифицировать .gear-tags в этом дереве, добавив туда реально использованные sha1 пришитых бранчей. > * Создаёт новый коммит1, который ссылается на новосозданное дерево, а > родителем числит прошлый release commit. Создаёт новый коммит2, > который ссылается на новосозданное дерево, но не имеет родителей. Откуда берётся прошлый release commit? Придётся заводить для таких коммитов какую-то специальную ветку. У коммит1, если уж делать его в таком виде, нужно вторым родителем ставить текущий коммит, иначе у того, что будет собираться, не будет никакой связи с реальной историей разработки. Впрочем, в gitk это всё равно будет выглядеть отвратительно - либо мегапатч, либо мега-merge. > * Создаёт и подписывает два тэга: release-$version с коммитом1 и > release-$version-bare с коммитом2. > > Теперь > - на новосозданные тэги можно применять gear в неизменённом виде. > - если .gear-tags пуст, то gear можно применять и на HEAD; если > .gear-tags непуст, то gear не найдёт в нём path* и отвалится. > Это напоминание сборщику, что HEAD требует применения gear-release. Это неудобно - как минимум, нужен wrapper, позволяющий вызвать gear одной командой (либо поддержка в самом gear). Вообще предполагалось, что gear-release используется при направлении окончательного релиза на сборку в Сизиф; в данном случае инструмент для сшивания деревьев придётся применять существенно чаще - вероятно, это должен быть не gear-release, а что-то другое. > - наследственность тэгов вида release-$version по-прежнему можно > проверять при входе в Сизиф, если считать, что майнтейнеры честны, > хотя, может быть, забывчивы. (Если майнтейнеры нечестны, то проверка > наследственности не помогает в любом случае.) > - тэги release-*-bare можно использовать, если нужно скачать все > исходники какой-то версии, и только их. Специальной поддержки со > стороны git не требуется. Соответствие $release и $release-bare > проверяется тривиально. От такого release-*-bare пользы примерно столько же, сколько и от git-archive --remote=... - при отсутствии связей между коммитами все объекты всегда передаются полностью (точнее, только с gzip-сжатием каждого объекта отдельно - количеством дельт между объектами одного дерева можно пренебречь). Экспериментальная проверка работы git с несвязанными коммитами на репозитории linux-2.6 показала следующее: - Размер pack-файла bare/v2.6.17 - 58M. - Размер pack-файла bare/v2.6.18 - 59M. Именно столько придётся вытянуть при получении bare/v2.6.18, не связанного с другими коммитами, даже при наличии в локальном репозитории bare/v2.6.17. - Размер pack-файла bare/v2.6.18, из которого исключены объекты, общие с деревом bare/v2.6.17 - 38M. Такой pack-файл придётся получить при выполнении git-fetch -k ... tag bare/v2.6.18-linked (этот тег указывает на коммит с деревом v2.6.18^{tree}, для которого в качестве единственного родительского коммита записан bare/v2.6.17^{commit}). При отсутствии связей между коммитами не удаётся получить даже такой результат. - Размер pack-файла bare/v2.6.18-linked, который сформирован с ключом --thin в предположении о наличии у клиента bare/v2.6.17 - 5,3M. Такой pack передаётся при выполнении git-fetch ... tag bare/v2.6.18-linked без опции -k. Вот так должен работать нормальный fetch с использованием родных протоколов git. Учитывая то, что на основе release-*-bare нельзя продолжать нормальную разработку (разве что чуть подпатчить spec - патчи для остальных компонентов уже не будут накладываться на исходный вариант из-за изменения путей), такой вариант даёт довольно мало преимуществ. Кроме того, имея подобный коммит, никак не связанный с остальной историей, невозможно получить изменения исходников относительно оригинальной версии (разве что в дерево для этого коммита будут помещаться оригинальные исходники и автоматически сформированные патчи). [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2006-09-26 11:49 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-09-21 19:20 Денис Смирнов 2006-09-22 5:57 ` Alexey Tourbin 2006-09-22 10:44 ` Денис Смирнов 2006-09-22 23:37 ` Dmitry V. Levin 2006-09-23 8:40 ` Денис Смирнов 2006-09-23 8:48 ` Dmitry V. Levin 2006-09-23 9:19 ` Денис Смирнов 2006-09-23 14:07 ` Dmitry V. Levin 2006-09-23 15:23 ` Sergey Vlasov 2006-09-23 15:54 ` Dmitry V. Levin 2006-09-23 16:04 ` Aleksey Avdeev 2006-09-23 16:16 ` Dmitry V. Levin 2006-09-23 16:38 ` Michael Shigorin 2006-09-23 16:51 ` Sergey Vlasov 2006-09-23 19:28 ` Dmitry V. Levin 2006-09-23 19:36 ` Денис Смирнов 2006-09-23 19:43 ` Dmitry V. Levin 2006-09-23 19:57 ` Sergey Vlasov 2006-09-23 22:56 ` Michael Shigorin 2006-09-26 19:01 ` Sergey Vlasov 2006-09-30 19:30 ` Sergey Vlasov 2006-10-03 22:11 ` Dmitry V. Levin 2006-10-15 16:08 ` Sergey Vlasov 2006-10-15 22:21 ` Dmitry V. Levin 2006-10-18 22:55 ` Dmitry V. Levin 2006-09-23 22:55 ` [devel] uranus Michael Shigorin 2006-09-25 5:24 ` Sergey Pinaev 2006-09-24 19:14 ` [devel] gear -- создание тарбола из другого branch Sergey Vlasov 2006-09-25 18:06 ` Sergey Vlasov 2006-09-25 20:01 ` Dmitry V. Levin 2006-09-26 17:34 ` Alexey I. Froloff 2006-09-26 18:21 ` Alexey I. Froloff 2006-09-25 8:09 ` Anton Farygin 2006-09-25 13:31 ` Sergey Vlasov 2006-09-25 20:06 ` Dmitry V. Levin 2006-09-26 8:42 ` Sergey Vlasov 2006-09-26 22:50 ` Dmitry V. Levin 2006-09-26 10:14 ` Alex V. Myltsev 2006-09-26 10:43 ` Alex V. Myltsev 2006-09-26 11:49 ` Sergey Vlasov [this message] 2006-09-26 13:01 ` Alex V. Myltsev 2006-09-26 14:25 ` Sergey Vlasov 2006-09-26 14:52 ` Alexey I. Froloff 2006-09-26 15:19 ` Sergey Vlasov 2006-09-23 15:28 ` Денис Смирнов 2006-10-02 23:32 ` Alexey Tourbin 2006-10-03 7:54 ` Денис Смирнов 2006-10-03 8:05 ` Alexey Tourbin 2006-10-03 11:19 ` Денис Смирнов 2006-10-03 11:25 ` Pavlov Konstantin 2006-10-03 14:36 ` Денис Смирнов 2006-10-03 14:46 ` Pavlov Konstantin 2006-10-03 22:25 ` Dmitry V. Levin 2006-10-04 8:02 ` Денис Смирнов
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20060926114904.GE18551@master.mivlgu.local \ --to=vsu@altlinux.ru \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git