[devel] git/gear и upstream

[devel] git/gear и upstream

[Artem Zolochevskiy]

hi all

продолжая изучать git/gear решил попробоваит его на примере пакета, где 
upstream -- это не я.

Вот какие есть вопросы к более опеытным:
upstream доступен в tar.gz

как организовать репозиторий?
что-то вроде:
бранч upstream (получаемый из периодических gear-update /path/to/tar.gz ... )
бранч master (.gear-rules + spec)
периодические merge перед выпуском нового пакета

или не городить upstream?

Какие есть +/-.

-- 
Артём Золочевский

Re: [devel] git/gear и upstream

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

On Sat, Aug 25, 2007 at 09:31:52PM +0300, Artem Zolochevskiy wrote:
> продолжая изучать git/gear решил попробоваит его на примере пакета, где 
> upstream -- это не я.
> 
> Вот какие есть вопросы к более опеытным:
> upstream доступен в tar.gz
> 
> как организовать репозиторий?
> что-то вроде:
> бранч upstream (получаемый из периодических gear-update /path/to/tar.gz ... )

Да, сделайте отдельный бранч, можно назвать его  tar.

> бранч master (.gear-rules + spec)
> периодические merge перед выпуском нового пакета
> 
> или не городить upstream?

Можно не городить upstrem, но тогда получается более хитрая процедура
обновления тарболла.  Если вносить изменения по месту исходников, а не
хранить патчи отдельно, то хотя бы временный бранч для мёжра с очередным
тарболлом всё равно потребуется.  То есть история линейной уже никак не
останется.

	 /M merge tarball v2
	* | tarball v2
	| * fix tarball/file2.c
	| * fix tarball/file1.c
	 `* tarball v1

По сути здесь не имеет значения, есть ли отдельный постоянный бранч для
tarball v2 или нет.

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

Подумайте также, удобно ли Вам класть содержимое тарболла в подкаталог
или нет.  Мне удобнее работать без подкаталога, но это делает
невозможным (при сохранении этой схемы) внесение в репозитарий ещё
одного тарболла.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] git/gear и upstream

[Artem Zolochevskiy]

В сообщении от Saturday 25 August 2007 22:06:39 Alexey Tourbin написал(а):

...

> Подумайте также, удобно ли Вам класть содержимое тарболла в подкаталог
> или нет.  Мне удобнее работать без подкаталога, но это делает
> невозможным (при сохранении этой схемы) внесение в репозитарий ещё
> одного тарболла.

Можно вот тут ещё пару слов?
В чём удобство?

-- 
Артём Золочевский

Re: [devel] git/gear и upstream

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

On Sat, Aug 25, 2007 at 10:36:58PM +0300, Artem Zolochevskiy wrote:
> > Подумайте также, удобно ли Вам класть содержимое тарболла в подкаталог
> > или нет.  Мне удобнее работать без подкаталога, но это делает
> > невозможным (при сохранении этой схемы) внесение в репозитарий ещё
> > одного тарболла.

Это удобство на уровне preferences.  Если все патчи приложены
к исходикам, то каталог вида %name/%name кажется мне лишним.

С другой стороны, gear-srpmimport предалагет именно такой каталог,
но и здесь можно изголиться, если очень захотеть.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] git/gear и upstream

[Artem Zolochevskiy]

В сообщении от Saturday 25 August 2007 22:54:42 Alexey Tourbin написал(а):
> On Sat, Aug 25, 2007 at 10:36:58PM +0300, Artem Zolochevskiy wrote:
> > > Подумайте также, удобно ли Вам класть содержимое тарболла в подкаталог
> > > или нет.  Мне удобнее работать без подкаталога, но это делает
> > > невозможным (при сохранении этой схемы) внесение в репозитарий ещё
> > > одного тарболла.
>
> Это удобство на уровне preferences.  Если все патчи приложены
> к исходикам, то каталог вида %name/%name кажется мне лишним.
>
> С другой стороны, gear-srpmimport предалагет именно такой каталог,
> но и здесь можно изголиться, если очень захотеть.

я попробую описать 2 способа работы с upstream доступным в tar.gz (на реальном 
примере fdups)

подскажите, что/где не так. что лишнее/чего не хватает.

я, правда, совсем не знаю, как это все будет если ещй и какие-то патчи есть.
мне и без патчей не так просто всё это понять.

итак:
1. upstream в отдельном бранче (upstream)

$ mkdir fdupes
$ cd fdupes
$ git init
$ tar xf ../archive/fdupes-1.0.tar.gz
$ ls
fdupes
(тут у меня каталог c исходниками с правильным именем получился, а если нет, 
то надо что-то вроде - $ mv fdupes-version  fdupes)
$ git add .
$ git commit -m "fdupes-1.0.tar.gz"
$ git tag -a -m "fdupes 1.0" v1.0 (делаем tag для этой версии исходников)
$ gear-update ../archive/fdupes-1.11.tar.gz fdupes
(обновляем исходники до версии 1.11)
$ git-commit -m "fdupes-1.11.tar.gz"
$ git tag -a -m "fdupes 1.11" v1.11 (делаем tag для этой версии исходников)

--> тут хочется это дело упаковать <--
$ git branch upstream (cохраняем все импортированные tar.gz в бранч upstream)
$ echo "tar: fdupes" > .gear-rules
$ vim fdupes.spec
$ git add  .gear-rules fdupes.spec
$ gear-commit
$ git tag -a -m "fdupes 1.11-alt1" 1.11-alt1
--> готово, версия 1.11-alt1 <--

-->вот положим вышла новая версия <--
(обновляем иcходники в бранче upstream)
$ git branch upstream
$ gear-update ../archive/fdupes-1.12.tar.gz fdupes
$ git commit -m "fdupes-1.12.tar.gz"
$ git tag -a -m "fdupes 1.12" v1.12
(пакуем)
$ git branch master
$ git merge v1.12 (добавляем новые исходники в master)
$ vim fdupes.spec
$ git add  fdupes.spec
$ gear-commit
$ git tag -a -m "fdupes 1.12-alt1" 1.12-alt1
--> готово, версия 1.12-alt1 <--

итд по кругу по мере выхода новых версий.

2. не городим upstream (тут, видимо, как-то надо хитро обновлять исходники)

$ tar xf archive/fdupes-1.0.tar.gz
(тут у меня каталог с правильным именем получился, а если нет, то надо что-то 
вроде - $ mv fdupes-version  fdupes)
$ cd fdupes
$ ls
fdupes.c  INSTALL  Makefile  README  runtest  testdir
$ git init
$ git add .
$ git commit -m "fdupes-1.0.tar.gz"
$ git tag -a -m "fdupes 1.0" v1.0 (делаем tag для этой версии исходников)

--> вот тут вопрос: как обновить исходники? <--
gear-updates тут поможет?

саму логику дальнейшей работы я понимаю так-то так:
$ git checkout -b temp v1.0 (временный бранч для иходников)
$ как-то обновляем иходники до новой версии (v1.11)
$ git commit -m "fdupes-1.11.tar.gz"
$ git tag -a -m "fdupes 1.11" v1.11 (делаем tag для этой версии исходников)
$ git branch -D temp
(я верно понимаю что бранч temp тут можно уже стирать?)

(пакуем)
$ git checkout master
$ echo "tar: fdupes" > .gear-rules
$ vim fdupes.spec
$ git add  .gear-rules fdupes.spec
$ gear-commit
$ git tag -a -m "fdupes 1.11-alt1" 1.11-alt1
--> готово, версия 1.11-alt1 <--

-->вот положим вышла новая версия <--
(обновляем иcходники)
$ git checkout temp v1.11
$ как-то обновляем иходники до новой версии (v1.12)
$ git commit -m "fdupes-1.11.tar.gz"
$ git tag -a -m "fdupes 1.11" v1.11 (делаем tag для этой версии исходников)
$ git branch -D temp
(я верно понимаю что бранч temp тут можно уже стирать?)

(пакуем)
$ git branch master
$ git merge v1.12 (добавляем новые исходники в master)
$ vim fdupes.spec
$ git add  fdupes.spec
$ gear-commit
$ git tag -a -m "fdupes 1.12-alt1" 1.12-alt1
--> готово, версия 1.12-alt1 <--

итд по кругу по мере выхода новых версий.


-- 
Артём Золочевский

Re: [devel] git/gear и upstream

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3421 bytes --]

On Sun, Aug 26, 2007 at 01:54:08PM +0300, Artem Zolochevskiy wrote:
> -->вот положим вышла новая версия <--
> (обновляем иcходники в бранче upstream)
> $ git branch upstream

git-checkout upstream

> $ gear-update ../archive/fdupes-1.12.tar.gz fdupes
> $ git commit -m "fdupes-1.12.tar.gz"
> $ git tag -a -m "fdupes 1.12" v1.12
> (пакуем)
> $ git branch master

Здесь тоже checkout

> $ git merge v1.12 (добавляем новые исходники в master)

Я обычно делаю типа (кажется это вредная привычка)
git-pull . upstream
а ещё можно делать
git-pull . tag vVER

> $ vim fdupes.spec
> $ git add  fdupes.spec

Повторно добавлять не надо, можно просто делать gear-commit -a.
Что-то я до конца не разобрался как там этот индекс обновляется.

> $ gear-commit
> $ git tag -a -m "fdupes 1.12-alt1" 1.12-alt1
> --> готово, версия 1.12-alt1 <--
> 
> итд по кругу по мере выхода новых версий.

Да, в целом всё так.

> 2. не городим upstream (тут, видимо, как-то надо хитро обновлять исходники)
> 
> $ tar xf archive/fdupes-1.0.tar.gz
> (тут у меня каталог с правильным именем получился, а если нет, то надо что-то 
> вроде - $ mv fdupes-version  fdupes)
> $ cd fdupes
> $ ls
> fdupes.c  INSTALL  Makefile  README  runtest  testdir
> $ git init
> $ git add .
> $ git commit -m "fdupes-1.0.tar.gz"
> $ git tag -a -m "fdupes 1.0" v1.0 (делаем tag для этой версии исходников)
> 
> --> вот тут вопрос: как обновить исходники? <--
> gear-updates тут поможет?

gear-update это какая-то странная штука, коммита она не делат,
зачем нужна не понял.  Если бы она после распаковки искала mtime
и делала коммит с этим mtime это было бы круче.

> саму логику дальнейшей работы я понимаю так-то так:
> $ git checkout -b temp v1.0 (временный бранч для иходников)
> $ как-то обновляем иходники до новой версии (v1.11)
> $ git commit -m "fdupes-1.11.tar.gz"
> $ git tag -a -m "fdupes 1.11" v1.11 (делаем tag для этой версии исходников)
> $ git branch -D temp
> (я верно понимаю что бранч temp тут можно уже стирать?)

Нужно будет сначала переключиться на другой бранч.

> (пакуем)
> $ git checkout master
> $ echo "tar: fdupes" > .gear-rules
> $ vim fdupes.spec
> $ git add  .gear-rules fdupes.spec
> $ gear-commit
> $ git tag -a -m "fdupes 1.11-alt1" 1.11-alt1
> --> готово, версия 1.11-alt1 <--
> 
> -->вот положим вышла новая версия <--
> (обновляем иcходники)
> $ git checkout temp v1.11
> $ как-то обновляем иходники до новой версии (v1.12)
> $ git commit -m "fdupes-1.11.tar.gz"
> $ git tag -a -m "fdupes 1.11" v1.11 (делаем tag для этой версии исходников)
> $ git branch -D temp
> (я верно понимаю что бранч temp тут можно уже стирать?)
> 
> (пакуем)
> $ git branch master
> $ git merge v1.12 (добавляем новые исходники в master)
> $ vim fdupes.spec
> $ git add  fdupes.spec
> $ gear-commit
> $ git tag -a -m "fdupes 1.12-alt1" 1.12-alt1
> --> готово, версия 1.12-alt1 <--
> 
> итд по кругу по мере выхода новых версий.

Насколько я понимаю, в этих двух вариантах у Вас получится полностью
аналогичная структура коммитов.

	  * updated spec for tar2
	 /M merged tar2
	* | tar2
	| * updated spec for tar1
	|/M merged tar1
	* | tar1
	| * added spec and .gear-rules
	0/  tar0

Будет ли какой-то бранч с отдельным названием в точке tar2,
не имеет значения.

Я думал Вы более тонкие вопросы спрашиваете, например как быть
поcле gear-srpmimport.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] git/gear и upstream

[Artem Zolochevskiy]

В сообщении от Sunday 26 August 2007 14:26:40 Alexey Tourbin написал(а):
> On Sun, Aug 26, 2007 at 01:54:08PM +0300, Artem Zolochevskiy wrote:
> > -->вот положим вышла новая версия <--
> > (обновляем иcходники в бранче upstream)
> > $ git branch upstream
>
> git-checkout upstream
>
> > $ gear-update ../archive/fdupes-1.12.tar.gz fdupes
> > $ git commit -m "fdupes-1.12.tar.gz"
> > $ git tag -a -m "fdupes 1.12" v1.12
> > (пакуем)
> > $ git branch master
>
> Здесь тоже checkout

Да, это я опечатался.

> > $ git merge v1.12 (добавляем новые исходники в master)
>
> Я обычно делаю типа (кажется это вредная привычка)
> git-pull . upstream
> а ещё можно делать
> git-pull . tag vVER
>
> > $ vim fdupes.spec
> > $ git add  fdupes.spec
>
> Повторно добавлять не надо, можно просто делать gear-commit -a.
> Что-то я до конца не разобрался как там этот индекс обновляется.
>
> > $ gear-commit
> > $ git tag -a -m "fdupes 1.12-alt1" 1.12-alt1
> > --> готово, версия 1.12-alt1 <--
> >
> > итд по кругу по мере выхода новых версий.
>
> Да, в целом всё так.

...

> Насколько я понимаю, в этих двух вариантах у Вас получится полностью
> аналогичная структура коммитов.
>
> 	  * updated spec for tar2
> 	 /M merged tar2
> 	* | tar2
>
> 	| * updated spec for tar1
> 	|/M merged tar1
>
> 	* | tar1
>
> 	| * added spec and .gear-rules
>
> 	0/  tar0
>
> Будет ли какой-то бранч с отдельным названием в точке tar2,
> не имеет значения.
>
> Я думал Вы более тонкие вопросы спрашиваете, например как быть
> поcле gear-srpmimport.

Нет, до тонкого пока далеко. С толстым разобраться бы...
Я просто поптался понять ваше указание на удобность хранить исходники без 
дополнительного подкаталога. Видимо, так пока и не понял. Похоже не время 
ещё.. :(


-- 
Артём Золочевский

Re: [devel] git/gear и upstream

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]

On Sun, Aug 26, 2007 at 07:07:57PM +0300, Artem Zolochevskiy wrote:
> Нет, до тонкого пока далеко. С толстым разобраться бы...
> Я просто поптался понять ваше указание на удобность хранить исходники без 
> дополнительного подкаталога. Видимо, так пока и не понял. Похоже не время 
> ещё.. :(

Да я не настаиваю, что это обязательно удобно.

Тонкость такая, что если архива сборок нет, то есть это новый пакет,
то и тонкостей никаких нет.  А если архив сборок есть, то будет два
варианта: импортировать сначала архив тарболлов, и "насаживать" архивные
сборки на эти тарболлы.  Получится похожая структура коммитов, как мы
обсуждали.
	  
	   /M [TAG v1.2-alt1] gear-srpmimport
	  * | tar v1.2
	  |/M [TAG v1.1-alt1] gear-srpmimport
	  *   tar v1.1
	  o   tar v1

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

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

	 /M merged new tar v2
	* | [TAG v2] imported tar v2 
	| * modified tarsrc/file2
	| * modified tarsrc/file1
	 `* gear-srpmimport 
	  * gear-srpmimport 
	  * gear-srpmimport 

Здесь будет такая тонкость, что в коммите "imported tar v2"
за пределами тарболльного каталога останутся старые "ошмётки"
от последнего "gear-srpmimport" в виде спека патчей и т.д.
То есть это будет как бы не "чисто тарболльный бранч", а
тарболльный бранч с артефактами от последнего srpmimport'а.
Эти артефакты лучше не удалять, хотя они там и будут смотреться
несколько странно.  Думаю что можно привыкнуть. :)

Ну или в принципе от них можно избавиться, только чтобы при мёрже
не было попыток "удаления".  Мёрж дело серьёзное.

А можно подцепить целое новое тарболльное дерево, которое начинается
из отдельного заземления.  Кажется ldv так делает.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] git/gear и upstream

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

On Sun, Aug 26, 2007 at 03:26:40PM +0400, Alexey Tourbin wrote:
[...]
> gear-update это какая-то странная штука, коммита она не делат,
> зачем нужна не понял.  Если бы она после распаковки искала mtime
> и делала коммит с этим mtime это было бы круче.

Я совсем недавно делал нечто вроде
$ gear-update --i /path/to/cpio-2.9.tar.bz2 cpio
$ faketime -r /path/to/cpio-2.9.tar.bz2 git commit -a -m ftp://ftp.gnu.org/gnu/cpio/cpio-2.9.tar.bz2
$ faketime -r /path/to/cpio-2.9.tar.bz2 git tag -a -m 'cpio 2.9' v2.9

Можно научить gear-update ключику --commit, который выполнит git commit с
правильным faketime, но откуда взять значение для -m?
Научить gear-update ключику --tag в рамках привычных (мне) соглашений
кажется проще.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] git/gear и upstream

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On Tue, Aug 28, 2007 at 09:17:36PM +0400, Dmitry V. Levin wrote:
> On Sun, Aug 26, 2007 at 03:26:40PM +0400, Alexey Tourbin wrote:
> [...]
> > gear-update это какая-то странная штука, коммита она не делат,
> > зачем нужна не понял.  Если бы она после распаковки искала mtime
> > и делала коммит с этим mtime это было бы круче.
> 
> Я совсем недавно делал нечто вроде
> $ gear-update --i /path/to/cpio-2.9.tar.bz2 cpio
> $ faketime -r /path/to/cpio-2.9.tar.bz2 git commit -a -m ftp://ftp.gnu.org/gnu/cpio/cpio-2.9.tar.bz2
> $ faketime -r /path/to/cpio-2.9.tar.bz2 git tag -a -m 'cpio 2.9' v2.9

Я ищу файл с максимальным mtime внутри тарболла.

> Можно научить gear-update ключику --commit, который выполнит git commit с
> правильным faketime, но откуда взять значение для -m?
> Научить gear-update ключику --tag в рамках привычных (мне) соглашений
> кажется проще.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] git/gear и upstream

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

On Tue, Aug 28, 2007 at 09:44:30PM +0400, Alexey Tourbin wrote:
> On Tue, Aug 28, 2007 at 09:17:36PM +0400, Dmitry V. Levin wrote:
> > On Sun, Aug 26, 2007 at 03:26:40PM +0400, Alexey Tourbin wrote:
> > [...]
> > > gear-update это какая-то странная штука, коммита она не делат,
> > > зачем нужна не понял.  Если бы она после распаковки искала mtime
> > > и делала коммит с этим mtime это было бы круче.
> > 
> > Я совсем недавно делал нечто вроде
> > $ gear-update --i /path/to/cpio-2.9.tar.bz2 cpio
> > $ faketime -r /path/to/cpio-2.9.tar.bz2 git commit -a -m ftp://ftp.gnu.org/gnu/cpio/cpio-2.9.tar.bz2
> > $ faketime -r /path/to/cpio-2.9.tar.bz2 git tag -a -m 'cpio 2.9' v2.9
> 
> Я ищу файл с максимальным mtime внутри тарболла.

Вряд ли это имеет смысл делать.
А если имеет, то можно написать самостоятельную утилитку.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]