ALT Linux Team development discussions
 help / color / mirror / Atom feed
* [devel] Простой пакет в git-репозитарии
@ 2008-04-07 10:18 Eugene Prokopiev
  2008-04-07 11:04 ` Damir Shayhutdinov
  2008-04-07 11:52 ` Dmitry V. Levin
  0 siblings, 2 replies; 5+ messages in thread
From: Eugene Prokopiev @ 2008-04-07 10:18 UTC (permalink / raw)
  To: ALT Linux Team development discussions

> >  Но очень неудобным (для меня, хотя, как я вижу, никого больше это не
>  >  смущает) является смешивание в одном каталоге оригинальных исходников
>  >  и моих файлов, необходимых для сборки rpm. Есть ли способ делать fetch
>  >  в подкаталог?
>
>
> Меня это уже давно не смущает. Держите спеки и gear-файлы в одной
>  ветке, а апстримные исходники - в другой. Перед выпуском просто
>  делаете с помощью git-merge -s ours фиктивный merge с веткой апстрима.
>
>  В .gear-rules при этом пишете что-то типа
>
>  tar.gz: upstream:.
>
>  Единственная неочевидная вещь в такой схеме - это как получить в
>  гит-репозитарии ветку, которая будет содержать спек и gear-rules, но
>  не будет содержать исходников.
>
>  Для этого создается пустой временный репозитарий, в него коммитится
>  спек и .gear-rules, потом ветку master оттуда надо будет втянуть в
>  основной репозитарий.

Последняя заметка в
http://freesource.info/wiki/AltLinux/Sisyphus/devel/git/gitnotes?

Процедура выглядит ужасно. Вы можете себе представить подобные
инструкции в официальном руководстве мантейнера? ;) Понятно, почему
его нет и не скоро будет :)

Нет ли более человечного способа создать в репозитарии 2 независимых
друг от друга бранча? Хотя, иметь репозитарий-заготовку с пустыми
спеком и .gear/rules - не такая уж плохая идея :) Еще лучше упихать
эту процедуру подальше от любопытных глаз в какой-нибудь gear-init,
который из тарболла делает репозитарий с рекомендуемой структурой. И
из src.rpm делает то же, т.е. с бранчами, а не с подкаталогом.

Итак, неавтоматизированная процедура создания простого пакета должна
выглядеть так:

$ mkdir mypackage
$ cd mypackage
$ git-init
$ touch file # здесь может быть извлечение апстримных исходников из
тарболла или из svn/cvs/git/...
$ git-add .
$ git-commit -a -m '0.1'
$ git-tag 0.1
$ git-tag last

теперь удаляем бранч master:

$ git-branch upstream
$ git-checkout upstream
$ git-branch -d master

и забираем его из другого временного репозитария:

$ mkdir ../tmp
$ cd ../tmp
$ git-init
$ mkdir .gear
$ echo "tar: last:." > .gear/rules
$ cat > mypackage.spec << EOF
> Name: mypackage
> Version: 0.1
...
> EOF
$ git-add .
$ git-commit -a -m 'initial commit'
$ cd ../mypackage
$ git-pull ../tmp master:master

Тут я получаю не совсем то, что ожидал:

$ PAGER=cat git-log
commit b76a9a3a744319406f52f6bdedee66b82f531052
Merge: c026f1b... 85de2c0...
Author: Eugene Prokopiev <enp@altlinux>
Date:   Mon Apr 7 13:33:35 2008 +0400

    Merge branch 'master' of ../tmp into upstream

commit c026f1b73a09deeaa932970af368e95b9013338c
Author: Eugene Prokopiev <enp@altlinux>
Date:   Mon Apr 7 13:32:37 2008 +0400

    0.1

commit 85de2c02397a9f23a6225cdff646fe25bbd15c08
Author: Eugene Prokopiev <enp@altlinux>
Date:   Mon Apr 7 13:21:55 2008 +0400

    initial commit

А как втянуть без merge? Мне ведь не нужны спек и .gear в upstream.
Сделал git-reset --hard HEAD^.

Теперь мержим (фиктивно) бранчи, обновляем ненужные нам теги (иначе
gear обидится - а почему они не нужны, я уже говорил: в бранче
upstream некрасиво иметь информацию об именах пакетов, тем более, что
на основании одного коммита может собираться несколько релизов; обход
чуть менее некрасивый - при каждом новом коммите в upstream двигаем
тег last на него) и собираем пакет:

$ git-checkout master
$ git-merge -s ours upstream
$ gear-update-tag -ac
$ gear -v --commit --rpmbuild -- rpm -bs --nodeps

Вроде все, остался последний коммит.

> В качестве примера посмотрите на liblazy у меня в git (а также
> почитайте ман к gear-rules и gear-update-tag).

Посмотрел туда и еще в парочку, сделал вывод, что общепринятой
структурой репозитария (если мы выносим апстримные исходники в
отдельный бранч) является такая:

$ git-branch -a
* (no branch)
  master
  origin/HEAD
  origin/master
  origin/upstream

Назначение master и origin/upstream понятно, будет ли последний
локальным или ремотным (интересно, а как его по-русски назвать?
"удаленный" - еще хуже) - зависит, как я понял, от того, используем мы
gear-update или git-svn fetch :)

Зачем нужны origin/HEAD и origin/master?

С более простыми схемами (alt-специфичные пакеты, в которых upstream
выделать смысла нет) и с более сложными с выделением каждого патча в
отдельный бранч вопросов вроде нет - наверное я еще не дорос до того,
чтобы их задавать :)

-- 
С уважением,
Прокопьев Евгений

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2008-04-07 11:52 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-04-07 10:18 [devel] Простой пакет в git-репозитарии Eugene Prokopiev
2008-04-07 11:04 ` Damir Shayhutdinov
2008-04-07 11:24   ` Eugene Prokopiev
2008-04-07 11:34     ` Damir Shayhutdinov
2008-04-07 11:52 ` Dmitry V. Levin

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