[devel] tar.gz в .gear-rules из другого git-репозитария

[devel] tar.gz в .gear-rules из другого git-репозитария

[Eugene Prokopiev]

Здравствуйте!

Я уже поднимал этот вопрос, но разобраться так и вышло ... попытаюсь еще 
раз. Итак, есть git-репозитарий (2 случая: локальный - 
~/git/dbmail-upstream/dbmail, полученный с помощью git-clone, и 
оригинальный - http://nfg3.nfgs.net/git/dbmail.git/). Какие строчки 
нужно написать в .gear-rules, чтобы из описанных выше репозитариев 
получить бранч dbmail_2_2, сжатый в tar.gz?

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

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
> Здравствуйте!
> 
> Я уже поднимал этот вопрос, но разобраться так и вышло ... попытаюсь еще 
> раз. Итак, есть git-репозитарий (2 случая: локальный - 
> ~/git/dbmail-upstream/dbmail, полученный с помощью git-clone, и 
> оригинальный - http://nfg3.nfgs.net/git/dbmail.git/). Какие строчки 
> нужно написать в .gear-rules, чтобы из описанных выше репозитариев 
> получить бранч dbmail_2_2, сжатый в tar.gz?

1. Втащить http://nfg3.nfgs.net/git/dbmail.git в
~/git/dbmail-upstream/dbmail отдельным бранчем (симейством бранчей)

2. man gear-rules на придмет создания траблов из отдельного бранча.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Eugene Prokopiev]

Aleksey Avdeev пишет:
> Eugene Prokopiev пишет:
> 
>>Здравствуйте!
>>
>>Я уже поднимал этот вопрос, но разобраться так и вышло ... попытаюсь еще 
>>раз. Итак, есть git-репозитарий (2 случая: локальный - 
>>~/git/dbmail-upstream/dbmail, полученный с помощью git-clone, и 
>>оригинальный - http://nfg3.nfgs.net/git/dbmail.git/). Какие строчки 
>>нужно написать в .gear-rules, чтобы из описанных выше репозитариев 
>>получить бранч dbmail_2_2, сжатый в tar.gz?

 > 1. Втащить http://nfg3.nfgs.net/git/dbmail.git в
 > ~/git/dbmail-upstream/dbmail отдельным бранчем (симейством бранчей)

man что? и хотя бы какая последовательность команд нужна после 
git-init-db, дальше буду пытаться читать ман по ним ...

> 2. man gear-rules на придмет создания траблов из отдельного бранча.

Читаю раздел PATHS. В вольном изложении он выглядит так: путь можно 
описывать только внутри главного дерева, за исключением:
1) . - указывает на текущее главное дерево - не подходит
2) идентификатор коммита в главном дереве - тоже не подходит
3) идентификатор тэга (какого, тут уже я запутался ...) - вроде тоже не 
подходит

Правильно ли я понял, что главное дерево - это и есть, собственно, мой 
репозитарий, сформированный с помощью git-init-db и заполненный с 
помощью gear-srpmimport, а другой репозитарий - это другое дерево? Или в 
репозитарии может быть несколько деревьев? Я понимаю, что по этому 
поводу нужно читать GIT Glossary, но я не настолько хорошо владею 
английским, чтобы вникнуть в предмет :(

И ответа на свой вопрос я в мане не нашел: как из .git-rules добраться 
до другого дерева?

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

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Vladimir V. Kamarzin]

>>>>> On 02 Apr 2007 at 17:41 "EP" == Eugene Prokopiev writes:

 EP> Правильно ли я понял, что главное дерево - это и есть, собственно, мой 
 EP> репозитарий, сформированный с помощью git-init-db и заполненный с 
 EP> помощью gear-srpmimport, а другой репозитарий - это другое дерево? Или в 

Главное дерево, это, видимо, бранч master.

 EP> И ответа на свой вопрос я в мане не нашел: как из .git-rules добраться 
 EP> до другого дерева?

Непосредственно сворачивать тарболы (tar: ) из других бранчей нельзя. Можно
использовать таги, принадлежащие другим бранчам, но в любом случае нужно
сделать pull (в данном случае с -s ours), чтобы появился common ancestor и
gear мог быть уверен в доступности этих тагов. vsu может объяснить подробнее
эту кухню...

-- 
vvk

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
> Aleksey Avdeev пишет:
>> Eugene Prokopiev пишет:
>>
>>> Здравствуйте!
>>>
>>> Я уже поднимал этот вопрос, но разобраться так и вышло ... попытаюсь еще 
>>> раз. Итак, есть git-репозитарий (2 случая: локальный - 
>>> ~/git/dbmail-upstream/dbmail, полученный с помощью git-clone, и 
>>> оригинальный - http://nfg3.nfgs.net/git/dbmail.git/). Какие строчки 
>>> нужно написать в .gear-rules, чтобы из описанных выше репозитариев 
>>> получить бранч dbmail_2_2, сжатый в tar.gz?
> 
>  > 1. Втащить http://nfg3.nfgs.net/git/dbmail.git в
>  > ~/git/dbmail-upstream/dbmail отдельным бранчем (симейством бранчей)
> 
> man что?

  man git-fetch

> и хотя бы какая последовательность команд нужна после 
> git-init-db, дальше буду пытаться читать ман по ним ...

  На вскидку:

git-fetch http://nfg3.nfgs.net/git/dbmail.git dbmail_2_2:dbmail_2_2

  После этого -- в текущем репозитарии получаем бранч dbmail_2_2,
совподающий с бранчем dbmail_2_2 оригинального
http://nfg3.nfgs.net/git/dbmail.git.

 Проблемму сдесь вижу токо 1: в http://nfg3.nfgs.net/git/dbmail.git
отсуствуют теги... Как миниум 1 придётся создавать самому (будет нужен
для ссылки из .git-rules, а
<http://nfg3.nfgs.net/git/dbmail.git/refs/tags/> пуст).

> 
>> 2. man gear-rules на придмет создания траблов из отдельного бранча.
> 
> Читаю раздел PATHS. В вольном изложении он выглядит так: путь можно 
> описывать только внутри главного дерева, за исключением:
> 1) . - указывает на текущее главное дерево - не подходит
> 2) идентификатор коммита в главном дереве - тоже не подходит
> 3) идентификатор тэга (какого, тут уже я запутался ...) - вроде тоже не 
> подходит

  Он самый. Но в вашем случаи -- про тег см. выше...

> 
> Правильно ли я понял, что главное дерево - это и есть, собственно, мой 
> репозитарий, сформированный с помощью git-init-db и заполненный с 
> помощью gear-srpmimport,

  Скорее всего да.

> а другой репозитарий - это другое дерево?

  Не факт: другой репозитарий может содержать дерево, совпадающее с
вашим главным частично.

> Или в 
> репозитарии может быть несколько деревьев?

  Да. В репозитарии могут содержаться несколько непересикаюшихся
бранчей. (Один из способов создания -- git-fetch из репозитария никак
несвязанного с вашим.)

> Я понимаю, что по этому 
> поводу нужно читать GIT Glossary, но я не настолько хорошо владею 
> английским, чтобы вникнуть в предмет :(
> 
> И ответа на свой вопрос я в мане не нашел: как из .git-rules добраться 
> до другого дерева?

  vvk@ в соседнем письме описал процесс весьма неплохо.

  Пример практического использования можно посмотреть у меня в
<http://git.altlinux.org/people/solo/packages/?p=apache2.git;a=summary>.
 (ВНИМАНИЕ! Данный репозитарий достаточно большой -- около 100 Мб.)
Смотреть лучше локально, с помощью gitk --all: тогда все слияния веток
(в том числе фиктивные, с -s ours) видны наглядно.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Eugene Prokopiev]

Vladimir V. Kamarzin пишет:
>>>>>>On 02 Apr 2007 at 17:41 "EP" == Eugene Prokopiev writes:
> 
> 
>  EP> Правильно ли я понял, что главное дерево - это и есть, собственно, мой 
>  EP> репозитарий, сформированный с помощью git-init-db и заполненный с 
>  EP> помощью gear-srpmimport, а другой репозитарий - это другое дерево? Или в 
> 
> Главное дерево, это, видимо, бранч master.
> 
>  EP> И ответа на свой вопрос я в мане не нашел: как из .git-rules добраться 
>  EP> до другого дерева?
> 
> Непосредственно сворачивать тарболы (tar: ) из других бранчей нельзя. Можно
> использовать таги, принадлежащие другим бранчам, но в любом случае нужно
> сделать pull (в данном случае с -s ours), чтобы появился common ancestor и
> gear мог быть уверен в доступности этих тагов. vsu может объяснить подробнее
> эту кухню...

Я понимаю, что царских путей в геометрии нет, но можно все же чуть ближе 
к конкретным примерам? Я должен, находясь в каталоге со своим 
репозитарием, сказать нечто вроде git pull ... и получить каталог, 
представляющий собой содержимое head некоего бранча другого репозитария? 
Что именно я должен сказать?

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

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
> Vladimir V. Kamarzin пишет:
>>>>>>> On 02 Apr 2007 at 17:41 "EP" == Eugene Prokopiev writes:
>>
>>  EP> Правильно ли я понял, что главное дерево - это и есть, собственно, мой 
>>  EP> репозитарий, сформированный с помощью git-init-db и заполненный с 
>>  EP> помощью gear-srpmimport, а другой репозитарий - это другое дерево? Или в 
>>
>> Главное дерево, это, видимо, бранч master.
>>
>>  EP> И ответа на свой вопрос я в мане не нашел: как из .git-rules добраться 
>>  EP> до другого дерева?
>>
>> Непосредственно сворачивать тарболы (tar: ) из других бранчей нельзя. Можно
>> использовать таги, принадлежащие другим бранчам, но в любом случае нужно
>> сделать pull (в данном случае с -s ours), чтобы появился common ancestor и
>> gear мог быть уверен в доступности этих тагов. vsu может объяснить подробнее
>> эту кухню...
> 
> Я понимаю, что царских путей в геометрии нет, но можно все же чуть ближе 
> к конкретным примерам? Я должен, находясь в каталоге со своим 
> репозитарием, сказать нечто вроде git pull ... и получить каталог, 
> представляющий собой содержимое head некоего бранча другого репозитария? 
> Что именно я должен сказать?

  Выложите свой репозитарий на git.alt (ссылку -- сюда) -- ночером
попробую глянуть... ;-)

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Eugene Prokopiev]

Aleksey Avdeev пишет:
> Eugene Prokopiev пишет:
> 
>>Aleksey Avdeev пишет:
>>
>>>Eugene Prokopiev пишет:
>>>
>>>
>>>>Здравствуйте!
>>>>
>>>>Я уже поднимал этот вопрос, но разобраться так и вышло ... попытаюсь еще 
>>>>раз. Итак, есть git-репозитарий (2 случая: локальный - 
>>>>~/git/dbmail-upstream/dbmail, полученный с помощью git-clone, и 
>>>>оригинальный - http://nfg3.nfgs.net/git/dbmail.git/). Какие строчки 
>>>>нужно написать в .gear-rules, чтобы из описанных выше репозитариев 
>>>>получить бранч dbmail_2_2, сжатый в tar.gz?
>>
>> > 1. Втащить http://nfg3.nfgs.net/git/dbmail.git в
>> > ~/git/dbmail-upstream/dbmail отдельным бранчем (симейством бранчей)
>>
>>man что?
> 
> 
>   man git-fetch
> 
> 
>>и хотя бы какая последовательность команд нужна после 
>>git-init-db, дальше буду пытаться читать ман по ним ...
> 
> 
>   На вскидку:
> 
> git-fetch http://nfg3.nfgs.net/git/dbmail.git dbmail_2_2:dbmail_2_2
> 
>   После этого -- в текущем репозитарии получаем бранч dbmail_2_2,
> совподающий с бранчем dbmail_2_2 оригинального
> http://nfg3.nfgs.net/git/dbmail.git.
> 
>  Проблемму сдесь вижу токо 1: в http://nfg3.nfgs.net/git/dbmail.git
> отсуствуют теги... Как миниум 1 придётся создавать самому (будет нужен
> для ссылки из .git-rules, а
> <http://nfg3.nfgs.net/git/dbmail.git/refs/tags/> пуст).

1. Не будет ли правильнее делать это внутри моего репозитария, в котором 
лежит спек и все необходимое для построения src.rpm?

2. В этом случае у меня в репозитарии должен появиться каталог 
dbmail_2_2, в котором будет head бранча dbmail_2_2?

3. Я должен создавать таг (т.е. выполнять git-tag -a tagname), находясь 
в каталоге dbmail_2_2? Имя этого тага можно будет использовать в 
.gear-rules? Откуда gear узнает о появлении тага, как он вообще будет 
связан с главным деревом? Для меня все это пока что мистика ...

4. Что произойдет с тагом, когда я еще раз выполню git-fetch (так ведь я 
должен буду обновлять бранч по мере необходимости?) ?

>>>2. man gear-rules на придмет создания траблов из отдельного бранча.
>>
>>Читаю раздел PATHS. В вольном изложении он выглядит так: путь можно 
>>описывать только внутри главного дерева, за исключением:
>>1) . - указывает на текущее главное дерево - не подходит
>>2) идентификатор коммита в главном дереве - тоже не подходит
>>3) идентификатор тэга (какого, тут уже я запутался ...) - вроде тоже не 
>>подходит
> 
> 
>   Он самый. Но в вашем случаи -- про тег см. выше...
> 
> 
>>Правильно ли я понял, что главное дерево - это и есть, собственно, мой 
>>репозитарий, сформированный с помощью git-init-db и заполненный с 
>>помощью gear-srpmimport,
> 
> 
>   Скорее всего да.
> 
> 
>>а другой репозитарий - это другое дерево?
> 
> 
>   Не факт: другой репозитарий может содержать дерево, совпадающее с
> вашим главным частично.
> 
> 
>>Или в 
>>репозитарии может быть несколько деревьев?
> 
> 
>   Да. В репозитарии могут содержаться несколько непересикаюшихся
> бранчей. (Один из способов создания -- git-fetch из репозитария никак
> несвязанного с вашим.)
> 
> 
>>Я понимаю, что по этому 
>>поводу нужно читать GIT Glossary, но я не настолько хорошо владею 
>>английским, чтобы вникнуть в предмет :(
>>
>>И ответа на свой вопрос я в мане не нашел: как из .git-rules добраться 
>>до другого дерева?
> 
> 
>   vvk@ в соседнем письме описал процесс весьма неплохо.
> 
>   Пример практического использования можно посмотреть у меня в
> <http://git.altlinux.org/people/solo/packages/?p=apache2.git;a=summary>.
>  (ВНИМАНИЕ! Данный репозитарий достаточно большой -- около 100 Мб.)
> Смотреть лучше локально, с помощью gitk --all: тогда все слияния веток
> (в том числе фиктивные, с -s ours) видны наглядно.

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

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

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
> Aleksey Avdeev пишет:
>> Eugene Prokopiev пишет:
>>
>>> Aleksey Avdeev пишет:
>>>
>>>> Eugene Prokopiev пишет:
>>>>
>>>>
>>>>> Здравствуйте!
>>>>>
>>>>> Я уже поднимал этот вопрос, но разобраться так и вышло ... попытаюсь еще 
>>>>> раз. Итак, есть git-репозитарий (2 случая: локальный - 
>>>>> ~/git/dbmail-upstream/dbmail, полученный с помощью git-clone, и 
>>>>> оригинальный - http://nfg3.nfgs.net/git/dbmail.git/). Какие строчки 
>>>>> нужно написать в .gear-rules, чтобы из описанных выше репозитариев 
>>>>> получить бранч dbmail_2_2, сжатый в tar.gz?
>>>> 1. Втащить http://nfg3.nfgs.net/git/dbmail.git в
>>>> ~/git/dbmail-upstream/dbmail отдельным бранчем (симейством бранчей)
>>> man что?
>>
>>   man git-fetch
>>
>>
>>> и хотя бы какая последовательность команд нужна после 
>>> git-init-db, дальше буду пытаться читать ман по ним ...
>>
>>   На вскидку:
>>
>> git-fetch http://nfg3.nfgs.net/git/dbmail.git dbmail_2_2:dbmail_2_2
                                                 ^^^^^^^^^^^^^^^^^^^^^
>>
>>   После этого -- в текущем репозитарии получаем бранч dbmail_2_2,
>> совподающий с бранчем dbmail_2_2 оригинального
>> http://nfg3.nfgs.net/git/dbmail.git.
>>
>>  Проблемму сдесь вижу токо 1: в http://nfg3.nfgs.net/git/dbmail.git
>> отсуствуют теги... Как миниум 1 придётся создавать самому (будет нужен
>> для ссылки из .git-rules, а
>> <http://nfg3.nfgs.net/git/dbmail.git/refs/tags/> пуст).
> 
> 1. Не будет ли правильнее делать это внутри моего репозитария, в котором 
> лежит спек и все необходимое для построения src.rpm?

  Непонял фразу...

> 
> 2. В этом случае у меня в репозитарии должен появиться каталог 
> dbmail_2_2, в котором будет head бранча dbmail_2_2?

  А зачем он?

> 
> 3. Я должен создавать таг (т.е. выполнять git-tag -a tagname), находясь 
> в каталоге dbmail_2_2? Имя этого тага можно будет использовать в 
> .gear-rules? Откуда gear узнает о появлении тага, как он вообще будет 
> связан с главным деревом? Для меня все это пока что мистика ...

  Забудте слово "каталог" для данной задачи. Выполнить git-tag -a
tagname нужно в _бранче_ dbmail_2_2 (если использован вызов git-fetch с
выделеным параметром).

> 
> 4. Что произойдет с тагом, когда я еще раз выполню git-fetch (так ведь я 
> должен буду обновлять бранч по мере необходимости?) ?

  Таг останется на месте, пока вы не сделаете git-tag -f -a tagname

> 
>>>> 2. man gear-rules на придмет создания траблов из отдельного бранча.
>>> Читаю раздел PATHS. В вольном изложении он выглядит так: путь можно 
>>> описывать только внутри главного дерева, за исключением:
>>> 1) . - указывает на текущее главное дерево - не подходит
>>> 2) идентификатор коммита в главном дереве - тоже не подходит
>>> 3) идентификатор тэга (какого, тут уже я запутался ...) - вроде тоже не 
>>> подходит
>>
>>   Он самый. Но в вашем случаи -- про тег см. выше...
>>
>>
>>> Правильно ли я понял, что главное дерево - это и есть, собственно, мой 
>>> репозитарий, сформированный с помощью git-init-db и заполненный с 
>>> помощью gear-srpmimport,
>>
>>   Скорее всего да.
>>
>>
>>> а другой репозитарий - это другое дерево?
>>
>>   Не факт: другой репозитарий может содержать дерево, совпадающее с
>> вашим главным частично.
>>
>>
>>> Или в 
>>> репозитарии может быть несколько деревьев?
>>
>>   Да. В репозитарии могут содержаться несколько непересикаюшихся
>> бранчей. (Один из способов создания -- git-fetch из репозитария никак
>> несвязанного с вашим.)
>>
>>
>>> Я понимаю, что по этому 
>>> поводу нужно читать GIT Glossary, но я не настолько хорошо владею 
>>> английским, чтобы вникнуть в предмет :(
>>>
>>> И ответа на свой вопрос я в мане не нашел: как из .git-rules добраться 
>>> до другого дерева?
>>
>>   vvk@ в соседнем письме описал процесс весьма неплохо.
>>
>>   Пример практического использования можно посмотреть у меня в
>> <http://git.altlinux.org/people/solo/packages/?p=apache2.git;a=summary>.
>>  (ВНИМАНИЕ! Данный репозитарий достаточно большой -- около 100 Мб.)
>> Смотреть лучше локально, с помощью gitk --all: тогда все слияния веток
>> (в том числе фиктивные, с -s ours) видны наглядно.
> 
> жаль, что нет никаких консольных инструментов для визуализации - сизиф у 
> меня пока что только на серверах (преимущественно виртуальных), на 
> рабочей станции, ноуте и дома - ALM 2.4 и нет времени переехать :(

  Если не ошибаюсь, то и git, и gitk есть в backports для ALM 2.4. ;-)

PS: Вы можете дать забрать откуда либо ваш репозитарий? (Мне желательно
его увидеть, для болие осмысленной ответов.)

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Eugene Prokopiev]

>   Выложите свой репозитарий на git.alt (ссылку -- сюда) -- ночером
> попробую глянуть... ;-)

http://git.altlinux.org/people/enp/packages/?p=dbmail.git;a=summary - 
это просто результат импорта из src.rpm, теперь нужно сделать правильно ;)

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

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
>>  Выложите свой репозитарий на git.alt (ссылку -- сюда) -- ночером
>>попробую глянуть... ;-)
> 
> 
> http://git.altlinux.org/people/enp/packages/?p=dbmail.git;a=summary - 
> это просто результат импорта из src.rpm, теперь нужно сделать правильно ;)
> 

  Правильность не обещаю, но то что получилось -- выложу, с описанием
процесса:

1. Клонирование <http://nfg3.nfgs.net/git/dbmail.git/>

  Процесс долгий и мучительный. Результат здесь:
<http://git.altlinux.ru/people/solo/packages/?p=dbmail.orig.git;a=summary>

  Дальнейшее -- из расчёта что сделано cd в каталог репозитария.

2. Расстановка тегов.

  Совсем паршиво. Похоже <http://nfg3.nfgs.net/git/dbmail.git/> -- это
только часть репозитария используемого автором. Нашёл тольк 1 коммит
соответствующий какой либо стабильной версии (отметеил как
dbmail/2.2.4)... Всё остальное -- репозитарий разработки (судя по
ChangeLog).

3. Загрузка dbmail-*.src.rpm "рядом"

  Для загрузки использовал патченую версию gear-srpmimport (можно взять
здесь:
<http://git.altlinux.org/people/solo/packages/?p=gear.git;a=shortlog;h=solo/comp-branches>),
позволяющую разложить компоненты srpm по отдельным бранчам и задавать
префикс для бранчей/тегов. (Для дальнейшей обработки мне так удобнее.
При использовании стандартной утилиты дальнейшее поменяется не сильно.)

$ gear-srpmimport --import-only --comp-branches --prefix=ALT/dbmail
dbmail-2.0.10-alt2.src.rpm

...

$ gear-srpmimport --import-only --comp-branches --prefix=ALT/dbmail
dbmail-2.2.1-alt5.0.src.rpm

  Прошу обратить внимание на --import-only: если его не указывать --
gear-srpmimport смержит созданый ей бранч с текущим. А нам, в данном
случаи, это не нужно.

  В дальнейшем -- исхожу из того, что надо сменить версию на 2.2.4
(ненашоёл, куда поставить теги на другие версии).

4. Редактируем .gear-rules:

а) Переходим в нужный бранч (у меня -- ALT/dbmail/gear_rules, по
умолчению -- в srpms, если параметрами небыло заданно другое)

$ git-checkout ALT/dbmail/gear_rules

б) Редактируем .gear_rules. Нам там нужно:

tar.gz: dbmail/2.2.4:. name=dbmail-2.2.4

в) Коммитим:

$ git-commit -a -s -m'Updete .gear_rules:
> - using dbmail/2.2.4 tsg
> '

5. Редактируем спек. Сдесь всё аналогично:

а) Переходим в нужный бранч, если это нужно (у меня нужно перейти в
ALT/dbmail/spec)

$ git-checkout ALT/dbmail/spec

б) Редактируем и коммитем.

6. Собираем все правки в кучу (если компаненты по бранчам не разделялись
-- это шаг не нужен)

$ git-checkout ALT/dbmail/srpms
$ git-merge 'Merging all components' HEAD ALT/dbmail/spec
ALT/dbmail/gear_rules

7. Удаляем старый каталог dbmail (он больше не нужен) и соммитим:

$ git-rm -f dbmail
...

$ git-commit -a -s -m 'Remove old dbmail/'

8. Подшиваем бранч упстрима:

$ git-merge -s ours 'Using upstream branch' HEAD dbmail/2.2.4

9. Обнавляем/создаём .gear-tags:

$ gear-update-tag -a

10. Соммитем всё это безобразие :-)

git-commit -a -s -m '- move to 2.2.4'

11. Проверяем, а всё ли у нас получилось:

$ gear --rpmbuild -- rpmbuild --nodeps -bs
Записан: /home/solo/RPM/SRPMS/dbmail-2.2.4-alt0.src.rpm
[solo@worksol dbmail.rpm]$ rpm -qlp
/home/solo/RPM/SRPMS/dbmail-2.2.4-alt0.src.rpm
dbmail-2.2.0-altlinux-as-need.patch
dbmail-2.2.1-fix-libdir.patch
dbmail-2.2.4.tar.gz
dbmail-clean
dbmail-imapd.init
dbmail-lmtpd.init
dbmail-pop3d.init
dbmail-timsieved.init
dbmail.conf
dbmail.spec

PS: Результат описанных опираций -- здесь:
<http://git.altlinux.ru/people/solo/packages/?p=dbmail.rpm.git;a=shortlog;h=ALT/dbmail/srpms>

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Hihin Ruslan]

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

Здравствуйте Aleksey Avdeev
  В сообщении от Вторник 03 апреля 2007 Aleksey Avdeev написал(a):
 > Eugene Prokopiev пишет:
 > >>  Выложите свой репозитарий на git.alt (ссылку -- сюда) -- ночером
....
 > PS: Результат описанных опираций -- здесь:
 >
 > <http://git.altlinux.ru/people/solo/packages/?p=dbmail.rpm.git;a=sho
 >rtlog;h=ALT/dbmail/srpms>

Алексей а не можно вас попросить выложить на Wiki ? Очень полезная 
информация - сейчас выучить не успею :). Но потом ещё не раз 
пригодится.
Уже пометил у себя в почтовике, как важное, но хорошо-бы это на Wiki 
иметь.. :)

-- 
С уважением Xихин Руслан

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

Re: [devel] tar.gz Б .gear-rules ХГ ДПСЦНЦН git-ПЕОНГХРЮПХЪ

[Aleksey Avdeev]

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

Hihin Ruslan пишет:
> Здравствуйте Aleksey Avdeev
>   В сообщении от Вторник 03 апреля 2007 Aleksey Avdeev написал(a):
>  > Eugene Prokopiev пишет:
>  > >>  Выложите свой репозитарий на git.alt (ссылку -- сюда) -- ночером
> ....
>  > PS: Результат описанных опираций -- здесь:
>  >
>  > <http://git.altlinux.ru/people/solo/packages/?p=dbmail.rpm.git;a=sho
>  >rtlog;h=ALT/dbmail/srpms>
> 
> Алексей а не можно вас попросить выложить на Wiki ? Очень полезная 
> информация - сейчас выучить не успею :). Но потом ещё не раз 
> пригодится.
> Уже пометил у себя в почтовике, как важное, но хорошо-бы это на Wiki 
> иметь.. :)

  OK. Ближе к вечеру -- сделаю.

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Eugene Prokopiev]

огромное спасибо, к вечеру попытаюсь воспроизвести - когда начнет не 
получаться, буду грузить дальше ;)

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

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Vladimir V. Kamarzin]

>>>>> On 02 Apr 2007 at 18:56 "EP" == Eugene Prokopiev writes:

>>  EP> И ответа на свой вопрос я в мане не нашел: как из .git-rules добраться 
>>  EP> до другого дерева?
>> 
>> Непосредственно сворачивать тарболы (tar: ) из других бранчей нельзя. Можно
>> использовать таги, принадлежащие другим бранчам, но в любом случае нужно
>> сделать pull (в данном случае с -s ours), чтобы появился common ancestor и
>> gear мог быть уверен в доступности этих тагов. vsu может объяснить подробнее
>> эту кухню...

 EP> Я понимаю, что царских путей в геометрии нет, но можно все же чуть ближе 
 EP> к конкретным примерам? Я должен, находясь в каталоге со своим 
 EP> репозитарием, сказать нечто вроде git pull ... и получить каталог, 
 EP> представляющий собой содержимое head некоего бранча другого репозитария? 
 EP> Что именно я должен сказать?

Вот небольшая заметка по использованию .gear-tags. Возможно, она поможет
прояснить тему :)
http://wiki.sisyphus.ru/devel/gear/gear-tags

-- 
vvk

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Eugene Prokopiev]

> 2. Расстановка тегов.
> 
>   Совсем паршиво. Похоже <http://nfg3.nfgs.net/git/dbmail.git/> -- это
> только часть репозитария используемого автором. Нашёл тольк 1 коммит
> соответствующий какой либо стабильной версии (отметеил как
> dbmail/2.2.4)... Всё остальное -- репозитарий разработки (судя по
> ChangeLog).

Простите, но придется начинать с совсем глупых вопросов:

1) Правильно ли я понимаю, что в отсутствии коммитов нет никакого 
криминала - просто хозяин репозитария синхронизируется с svn, вытягивая 
оттуда обновления, но сам ничего не коммитит? Или отсутствие коммитов - 
это плохо, и мне лучше все-таки синхронизироваться с svn?

2) Как вы искали коммиты? Т.е. куда именно смотреть в gitk и как 
получить список коммитов с помощью git-*? git-show и gitk показывают 
нечто с идентификатором 47e456d522365574e24b2455c59a79a94cc3e8e0 - это и 
есть единственный коммит? Еще я вижу:

$ git-show-branch
[master] resync

$ git-show-ref
47e456d522365574e24b2455c59a79a94cc3e8e0 refs/heads/master
47e456d522365574e24b2455c59a79a94cc3e8e0 refs/remotes/origin/HEAD
17c715778e695ce1c4dc46f9d10a79bd6661fa66 refs/remotes/origin/dbmail_2_2
784c1362118790ec0a0190327743fdef7a1763cf 
refs/remotes/origin/dbmail_2_3_workers
47e456d522365574e24b2455c59a79a94cc3e8e0 refs/remotes/origin/master

И чувствую, что как раз refs/remotes/origin/dbmail_2_2 и есть то, что 
мне нужно - ссылка на стабильную ветку 2.2, но это не бранч, бранч у 
нас, получается, только один - master.

Можно ли генерировать тарболл, основываясь на ссылке 
refs/remotes/origin/dbmail_2_2? И как просто извлечь исходники, 
соотвествующие ей?

Почему вы вместо этого отметили коммит 
47e456d522365574e24b2455c59a79a94cc3e8e0? И какой командой вы это сделали?

Остальное в первом приближении понятно, попробую позже воспроизвести ...

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

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
>>2. Расстановка тегов.
>>
>>  Совсем паршиво. Похоже <http://nfg3.nfgs.net/git/dbmail.git/> -- это
>>только часть репозитария используемого автором. Нашёл тольк 1 коммит
>>соответствующий какой либо стабильной версии (отметеил как
>>dbmail/2.2.4)... Всё остальное -- репозитарий разработки (судя по
>>ChangeLog).
> 
> 
> Простите, но придется начинать с совсем глупых вопросов:
> 
> 1) Правильно ли я понимаю, что в отсутствии коммитов нет никакого 
> криминала - просто хозяин репозитария синхронизируется с svn, вытягивая 
> оттуда обновления, но сам ничего не коммитит? Или отсутствие коммитов - 
> это плохо, и мне лучше все-таки синхронизироваться с svn?

  Коммиты как раз есть (они всегда есть, если репозитарий не пуст).
Невидно тегов: <http://nfg3.nfgs.net/git/dbmail.git/refs/tags/>
девственно пуст.

> 
> 2) Как вы искали коммиты? Т.е. куда именно смотреть в gitk и как 
> получить список коммитов с помощью git-*?

  Искал просмотром ChangeLog (с помощью gitk) в коммитах близких ко
времени создания траблов, выложенных здесь:
<http://www.dbmail.org/index.php?page=download>. + Сравнивал форматы
ChangeLog -- у рабочих веток и релизов они отличаются достаточно сильно.

> git-show и gitk показывают 
> нечто с идентификатором 47e456d522365574e24b2455c59a79a94cc3e8e0 - это и 
> есть единственный коммит? Еще я вижу:
> 
> $ git-show-branch
> [master] resync
> 
> $ git-show-ref
> 47e456d522365574e24b2455c59a79a94cc3e8e0 refs/heads/master
> 47e456d522365574e24b2455c59a79a94cc3e8e0 refs/remotes/origin/HEAD
> 17c715778e695ce1c4dc46f9d10a79bd6661fa66 refs/remotes/origin/dbmail_2_2
> 784c1362118790ec0a0190327743fdef7a1763cf 
> refs/remotes/origin/dbmail_2_3_workers
> 47e456d522365574e24b2455c59a79a94cc3e8e0 refs/remotes/origin/master
> 
> И чувствую, что как раз refs/remotes/origin/dbmail_2_2 и есть то, что 
> мне нужно - ссылка на стабильную ветку 2.2, но это не бранч, бранч у 
> нас, получается, только один - master.

  В приведённом вами -- да. Но я наблюдаю (вчера и в данный момент)
несколько другую картину:

1. <http://nfg3.nfgs.net/git/dbmail.git/refs/tags/> -- пуст

2. <http://nfg3.nfgs.net/git/dbmail.git/refs/tags/> -- пуст

3. <http://nfg3.nfgs.net/git/dbmail.git/refs/heads/> -- содержит
dbmail_2_2, dbmail_2_3_workers и master. Это всё бранчи (судя по
местоположению).

  То что закачал вчера:

$ git-show-ref
17c715778e695ce1c4dc46f9d10a79bd6661fa66 refs/heads/dbmail_2_2
784c1362118790ec0a0190327743fdef7a1763cf refs/heads/dbmail_2_3_workers
47e456d522365574e24b2455c59a79a94cc3e8e0 refs/heads/master
47e456d522365574e24b2455c59a79a94cc3e8e0 refs/heads/origin
0f6f20144ee5e5035c54a42a14b6289a324bbe89 refs/tags/dbmail/2.2.4

  Тэг здесь только 1 -- dbmail/2.2.4
(0f6f20144ee5e5035c54a42a14b6289a324bbe89), созданный мной.

> 
> Можно ли генерировать тарболл, основываясь на ссылке 
> refs/remotes/origin/dbmail_2_2?

  Подозреваю что нет: Судя по содержимому и формату ChangeLog`а это
ветка разработки. И факт, что найдётся некий dbmail-2.2.x
соответствующий коммиту 17c715778e695ce1c4dc46f9d10a79bd6661fa66.
Вероятность того, что это один из промежуточных (от dbmail-2.2.x к
dbmail-2.2.y) коммитов, на мой взгляд, выше.

> И как просто извлечь исходники, 
> соотвествующие ей?
> 
> Почему вы вместо этого отметили коммит 
> 47e456d522365574e24b2455c59a79a94cc3e8e0?

  Из -за его комментария: "2.2.4 release". + по содержимому ChangeLog`а
он похож на результат распаковки
<http://www.dbmail.org/download/2.2/dbmail-2.2.4.tar.gz>

> И какой командой вы это сделали?

  git-tag

> 
> Остальное в первом приближении понятно, попробую позже воспроизвести ...

  Общие мысли, касательно ситуации:

1. Судя по использованию конструкций вида refs/remotes/... -- автор
использует git-svn: на refs/remotes/<имя бранча> данное средство
отображает содержимое branches SVN репозитария.

2. Теги могут быть потеряны при неаккуратном git-push, выполненным
автором (я на это нарывался).

3. Судя по тому, что репозитарии выкаченные в разное время вами и мной
отличаются по структуре -- проект на стадии смены инфраструктуры хранения...

  Думаю, стоит списаться непосредственно с автором.

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] tar.gz Б .gear-rules ХГ ДПСЦНЦН git-ПЕОНГХРЮПХЪ

[Aleksey Avdeev]

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

Aleksey Avdeev пишет:
> Hihin Ruslan пишет:
> 
>>Здравствуйте Aleksey Avdeev
>>  В сообщении от Вторник 03 апреля 2007 Aleksey Avdeev написал(a):
>> > Eugene Prokopiev пишет:
>> > >>  Выложите свой репозитарий на git.alt (ссылку -- сюда) -- ночером
>>....
>> > PS: Результат описанных опираций -- здесь:
>> >
>> > <http://git.altlinux.ru/people/solo/packages/?p=dbmail.rpm.git;a=sho
>> >rtlog;h=ALT/dbmail/srpms>
>>
>>Алексей а не можно вас попросить выложить на Wiki ? Очень полезная 
>>информация - сейчас выучить не успею :). Но потом ещё не раз 
>>пригодится.
>>Уже пометил у себя в почтовике, как важное, но хорошо-бы это на Wiki 
>>иметь.. :)
> 
> 
>   OK. Ближе к вечеру -- сделаю.

  <http://wiki.sisyphus.ru/devel/gear/ImportUpstreamVBranch>

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Eugene Prokopiev]

>   То что закачал вчера:
> 
> $ git-show-ref
> 17c715778e695ce1c4dc46f9d10a79bd6661fa66 refs/heads/dbmail_2_2
> 784c1362118790ec0a0190327743fdef7a1763cf refs/heads/dbmail_2_3_workers
> 47e456d522365574e24b2455c59a79a94cc3e8e0 refs/heads/master
> 47e456d522365574e24b2455c59a79a94cc3e8e0 refs/heads/origin
> 0f6f20144ee5e5035c54a42a14b6289a324bbe89 refs/tags/dbmail/2.2.4
> 
>   Тэг здесь только 1 -- dbmail/2.2.4
> (0f6f20144ee5e5035c54a42a14b6289a324bbe89), созданный мной.

Очень странно. Я сейчас сделал git-fetch и увидел то, что и видел 
раньше: в heads только master, в remotes/origin - HEAD, dbmail_2_2, 
dbmail_2_3_workers, master. У вас есть какие-нибудь предположения, 
отчего может быть такая разница?

>>Можно ли генерировать тарболл, основываясь на ссылке 
>>refs/remotes/origin/dbmail_2_2?
> 
> 
>   Подозреваю что нет: Судя по содержимому и формату ChangeLog`а это
> ветка разработки. И факт, что найдётся некий dbmail-2.2.x
> соответствующий коммиту 17c715778e695ce1c4dc46f9d10a79bd6661fa66.
> Вероятность того, что это один из промежуточных (от dbmail-2.2.x к
> dbmail-2.2.y) коммитов, на мой взгляд, выше.

Да, но именно тарболл с самыми свежими изменениями на пути к 
dbmail-2.2.5 мне и нужен. Попутный вопрос: как правильно именовать 
пакет, собранный из такого промежуточного тарболла?

>>И как просто извлечь исходники, 
>>соотвествующие ей?

Т.е. вопрос актуален

>>Почему вы вместо этого отметили коммит 
>>47e456d522365574e24b2455c59a79a94cc3e8e0?
> 
> 
>   Из -за его комментария: "2.2.4 release". + по содержимому ChangeLog`а
> он похож на результат распаковки
> <http://www.dbmail.org/download/2.2/dbmail-2.2.4.tar.gz>
> 
>>И какой командой вы это сделали?
> 
> 
>   git-tag

Это я понял ;) Меня интересовали параметры, таг ведь вроде должен 
создаваться на основе какого-то коммита (?), но в man git-tag я этого не 
нашел :(

>>Остальное в первом приближении понятно, попробую позже воспроизвести ...
> 
> 
>   Общие мысли, касательно ситуации:
> 
> 1. Судя по использованию конструкций вида refs/remotes/... -- автор
> использует git-svn: на refs/remotes/<имя бранча> данное средство
> отображает содержимое branches SVN репозитария.
> 
> 2. Теги могут быть потеряны при неаккуратном git-push, выполненным
> автором (я на это нарывался).
> 
> 3. Судя по тому, что репозитарии выкаченные в разное время вами и мной
> отличаются по структуре -- проект на стадии смены инфраструктуры хранения...

Речь о git-репозитарии или о svn? Просто я только что сделал git-fetch, 
а того, о чем вы говорите, не вижу :(

>   Думаю, стоит списаться непосредственно с автором.

Автор ни о каких подводных камнях не упоминал, когда давал ссылку на git 
-репозитарий. Мне, собственно, нужна возможность делать пакеты на основе 
промежуточных версий от 2.2.4 до 2.2.5 и далее (чтобы оперативно 
устранять критичные для меня проблемы, пофикшенные апстримом). Может 
дешевле делать это на основе svn-репозитария (чтобы избежать проблемы 
2)? В svn, кстати, тоже перестали делать таги после 2.0. Это значит, что 
тарболлы для загрузки делаются просто на основе каких-либо коммитов 
(возможно последних в бранче на момент создания тарболла)?

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

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
>>  То что закачал вчера:
>>
>>$ git-show-ref
>>17c715778e695ce1c4dc46f9d10a79bd6661fa66 refs/heads/dbmail_2_2
>>784c1362118790ec0a0190327743fdef7a1763cf refs/heads/dbmail_2_3_workers
>>47e456d522365574e24b2455c59a79a94cc3e8e0 refs/heads/master
>>47e456d522365574e24b2455c59a79a94cc3e8e0 refs/heads/origin
>>0f6f20144ee5e5035c54a42a14b6289a324bbe89 refs/tags/dbmail/2.2.4
>>
>>  Тэг здесь только 1 -- dbmail/2.2.4
>>(0f6f20144ee5e5035c54a42a14b6289a324bbe89), созданный мной.
> 
> 
> Очень странно. Я сейчас сделал git-fetch и увидел то, что и видел 
> раньше: в heads только master, в remotes/origin - HEAD, dbmail_2_2, 
> dbmail_2_3_workers, master. У вас есть какие-нибудь предположения, 
> отчего может быть такая разница?

  Я не делал git-fetch, но делал git-clone. Плюс смотрел броузером
непосредственно по следующим адресам:

1. <http://nfg3.nfgs.net/git/dbmail.git/remotes/>

2. <http://nfg3.nfgs.net/git/dbmail.git/refs/tags/>

3. <http://nfg3.nfgs.net/git/dbmail.git/refs/heads/>


> 
> 
>>>Можно ли генерировать тарболл, основываясь на ссылке 
>>>refs/remotes/origin/dbmail_2_2?
>>
>>
>>  Подозреваю что нет: Судя по содержимому и формату ChangeLog`а это
>>ветка разработки. И факт, что найдётся некий dbmail-2.2.x
>>соответствующий коммиту 17c715778e695ce1c4dc46f9d10a79bd6661fa66.
>>Вероятность того, что это один из промежуточных (от dbmail-2.2.x к
>>dbmail-2.2.y) коммитов, на мой взгляд, выше.
> 
> 
> Да, но именно тарболл с самыми свежими изменениями на пути к 
> dbmail-2.2.5 мне и нужен. Попутный вопрос: как правильно именовать 
> пакет, собранный из такого промежуточного тарболла?

  2.2.4.x?

  ИМХО: Самый последний трабл (не отмеченный как релиз и/или RC) брать
возможно и не стоит: кто знает, что там сломано на пути к релизу... (Но
в любом случаи это вам виднее: я не в контексте.)

> 
> 
>>>И как просто извлечь исходники, 
>>>соотвествующие ей?
> 
> 
> Т.е. вопрос актуален
> 
> 
>>>Почему вы вместо этого отметили коммит 
>>>47e456d522365574e24b2455c59a79a94cc3e8e0?
>>
>>
>>  Из -за его комментария: "2.2.4 release". + по содержимому ChangeLog`а
>>он похож на результат распаковки
>><http://www.dbmail.org/download/2.2/dbmail-2.2.4.tar.gz>
>>
>>>И какой командой вы это сделали?
>>
>>
>>  git-tag
> 
> 
> Это я понял ;) Меня интересовали параметры, таг ведь вроде должен 
> создаваться на основе какого-то коммита (?), но в man git-tag я этого не 
> нашел :(

  git-tag -a -m 'dbmail 2.2.4' dbmail/2.2.4
8933d53ab39c352cc0ffdb8dfe44cae901a5c0f7

> 
> 
>>>Остальное в первом приближении понятно, попробую позже воспроизвести ...
>>
>>
>>  Общие мысли, касательно ситуации:
>>
>>1. Судя по использованию конструкций вида refs/remotes/... -- автор
>>использует git-svn: на refs/remotes/<имя бранча> данное средство
>>отображает содержимое branches SVN репозитария.
>>
>>2. Теги могут быть потеряны при неаккуратном git-push, выполненным
>>автором (я на это нарывался).
>>
>>3. Судя по тому, что репозитарии выкаченные в разное время вами и мной
>>отличаются по структуре -- проект на стадии смены инфраструктуры хранения...
> 
> 
> Речь о git-репозитарии или о svn? Просто я только что сделал git-fetch, 
> а того, о чем вы говорите, не вижу :(

  О <http://nfg3.nfgs.net/git/dbmail.git>.

  git-fetch может и не показывать: он забирает коммиты, но несохраняет
структуру репозитария. Точнее, по умолчанию, он укладывает забранные
коммиты в существующую структуру репозитария. (Прошу знатоков git меня
поправить, если не прав.)

> 
>>  Думаю, стоит списаться непосредственно с автором.
> 
> 
> Автор ни о каких подводных камнях не упоминал, когда давал ссылку на git 
> -репозитарий. Мне, собственно, нужна возможность делать пакеты на основе 
> промежуточных версий от 2.2.4 до 2.2.5 и далее (чтобы оперативно 
> устранять критичные для меня проблемы, пофикшенные апстримом). Может 
> дешевле делать это на основе svn-репозитария (чтобы избежать проблемы 
> 2)? В svn, кстати, тоже перестали делать таги после 2.0. Это значит, что 
> тарболлы для загрузки делаются просто на основе каких-либо коммитов 
> (возможно последних в бранче на момент создания тарболла)?

  Может быть. По изменению формата ChangeLog оно похоже (ChangeLog у
2.0.x -- другой по структуре). Но это стоит уточнить непосредственно у
автора.

  Если такой вариант имеет место -- то просто создавайте тэги в нужных
вам местах. Или, как вариант -- в нужных местах создавайте тег с
постоянным именем (через "git-tag -f -a -m 'dbmail 2.2.4.x for rpmbuild'
 dbmail/2.2.4-rpm XXXXX"), и неважно, что это будут разные коммиты (если
про gear-update-tag не забывать).

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Eugene Prokopiev]

>>>3. Судя по тому, что репозитарии выкаченные в разное время вами и мной
>>>отличаются по структуре -- проект на стадии смены инфраструктуры хранения...
>>
>>
>>Речь о git-репозитарии или о svn? Просто я только что сделал git-fetch, 
>>а того, о чем вы говорите, не вижу :(
> 
> 
>   О <http://nfg3.nfgs.net/git/dbmail.git>.
> 
>   git-fetch может и не показывать: он забирает коммиты, но несохраняет
> структуру репозитария. Точнее, по умолчанию, он укладывает забранные
> коммиты в существующую структуру репозитария. (Прошу знатоков git меня
> поправить, если не прав.)

А каким образом можно забрать не только новые коммиты, но и обновить 
структуру?

git-svnimport тоже будет просто забрать новые коммиты, а обновлять 
структуру не будет?

>>> Думаю, стоит списаться непосредственно с автором.
>>
>>
>>Автор ни о каких подводных камнях не упоминал, когда давал ссылку на git 
>>-репозитарий. Мне, собственно, нужна возможность делать пакеты на основе 
>>промежуточных версий от 2.2.4 до 2.2.5 и далее (чтобы оперативно 
>>устранять критичные для меня проблемы, пофикшенные апстримом). Может 
>>дешевле делать это на основе svn-репозитария (чтобы избежать проблемы 
>>2)? В svn, кстати, тоже перестали делать таги после 2.0. Это значит, что 
>>тарболлы для загрузки делаются просто на основе каких-либо коммитов 
>>(возможно последних в бранче на момент создания тарболла)?
> 
> 
>   Может быть. По изменению формата ChangeLog оно похоже (ChangeLog у
> 2.0.x -- другой по структуре). Но это стоит уточнить непосредственно у
> автора.

"Может быть" относится к использованию svn-репозитария вместо git или к 
отсутствию тагов после 2.0? Последнее вроде очевидно, у авторов можно 
только уточнять, каким образом делаются тарболлы.

>   Если такой вариант имеет место -- то просто создавайте тэги в нужных
> вам местах. Или, как вариант -- в нужных местах создавайте тег с
> постоянным именем (через "git-tag -f -a -m 'dbmail 2.2.4.x for rpmbuild'
>  dbmail/2.2.4-rpm XXXXX"), и неважно, что это будут разные коммиты (если
> про gear-update-tag не забывать).

Второй вариант не совсем понял. Что такое ХХХХХ? Имя бранча? Т.е. после 
gear-update-tag этот таг будет ссылаться на самый последний коммит в бранче?

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

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
>>>>3. Судя по тому, что репозитарии выкаченные в разное время вами и мной
>>>>отличаются по структуре -- проект на стадии смены инфраструктуры хранения...
>>>
>>>
>>>Речь о git-репозитарии или о svn? Просто я только что сделал git-fetch, 
>>>а того, о чем вы говорите, не вижу :(
>>
>>
>>  О <http://nfg3.nfgs.net/git/dbmail.git>.
>>
>>  git-fetch может и не показывать: он забирает коммиты, но несохраняет
>>структуру репозитария. Точнее, по умолчанию, он укладывает забранные
>>коммиты в существующую структуру репозитария. (Прошу знатоков git меня
>>поправить, если не прав.)
> 
> 
> А каким образом можно забрать не только новые коммиты, но и обновить 
> структуру?

  В данном случаи (инструкция с <http://wiki.sisyphus.ru/devel/git>):

1. Смотрим на предмет, что там есть по факту (каюсь, забыл это сделать
ранее):

$ git ls-remote http://nfg3.nfgs.net/git/dbmail.git
13d07dc880657547716e9ae22a8c7ed1deb27e18   refs/heads/dbmail_2_2
784c1362118790ec0a0190327743fdef7a1763cf   refs/heads/dbmail_2_3_workers
0b3397fc5b3765390ee984ea31b5959412a08286   refs/heads/master

2. Забираем нужное, кладя в нужное нам место (в данном случаи -- оно
должно совпадать с источником, кроме бранча master -- его возможно стоит
заменить на origin):

$ git-fetch http://nfg3.nfgs.net/git/dbmail.git
refs/heads/dbmail_2_2:refs/heads/dbmail_2_2

...

$ git-fetch http://nfg3.nfgs.net/git/dbmail.git
refs/heads/dbmail_2_2_workers:refs/heads/dbmail_2_2_workers
...


$ git-fetch http://nfg3.nfgs.net/git/dbmail.git
refs/heads/master:refs/heads/origin

> 
> git-svnimport тоже будет просто забрать новые коммиты, а обновлять 
> структуру не будет?

  Если появились новые бранчи/таги -- он их добавит, но не более.

> 
> 
>>>>Думаю, стоит списаться непосредственно с автором.
>>>
>>>
>>>Автор ни о каких подводных камнях не упоминал, когда давал ссылку на git 
>>>-репозитарий. Мне, собственно, нужна возможность делать пакеты на основе 
>>>промежуточных версий от 2.2.4 до 2.2.5 и далее (чтобы оперативно 
>>>устранять критичные для меня проблемы, пофикшенные апстримом). Может 
>>>дешевле делать это на основе svn-репозитария (чтобы избежать проблемы 
>>>2)? В svn, кстати, тоже перестали делать таги после 2.0. Это значит, что 
>>>тарболлы для загрузки делаются просто на основе каких-либо коммитов 
>>>(возможно последних в бранче на момент создания тарболла)?
>>
>>
>>  Может быть. По изменению формата ChangeLog оно похоже (ChangeLog у
>>2.0.x -- другой по структуре). Но это стоит уточнить непосредственно у
>>автора.
> 
> 
> "Может быть" относится к использованию svn-репозитария вместо git или к 
> отсутствию тагов после 2.0?

  К отсутствию тагов.

> Последнее вроде очевидно, у авторов можно 
> только уточнять, каким образом делаются тарболлы.

  Да.

> 
> 
>>  Если такой вариант имеет место -- то просто создавайте тэги в нужных
>>вам местах. Или, как вариант -- в нужных местах создавайте тег с
>>постоянным именем (через "git-tag -f -a -m 'dbmail 2.2.4.x for rpmbuild'
>> dbmail/2.2.4-rpm XXXXX"), и неважно, что это будут разные коммиты (если
>>про gear-update-tag не забывать).
> 
> 
> Второй вариант не совсем понял. Что такое ХХХХХ? Имя бранча?

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

> Т.е. после 
> gear-update-tag этот таг будет ссылаться на самый последний коммит в бранче?

  Таг будет ссылаться на то, что вы ему указали.

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Eugene Prokopiev]

>>> Если такой вариант имеет место -- то просто создавайте тэги в нужных
>>>вам местах. Или, как вариант -- в нужных местах создавайте тег с
>>>постоянным именем (через "git-tag -f -a -m 'dbmail 2.2.4.x for rpmbuild'
>>>dbmail/2.2.4-rpm XXXXX"), и неважно, что это будут разные коммиты (если
>>>про gear-update-tag не забывать).
>>
>>
>>Второй вариант не совсем понял. Что такое ХХХХХ? Имя бранча?
> 
> 
>   То что вам надо: это может быть хеш коммита, имя бранча и, по моему --
> существующий таг (здесь могу ошибаться).
> 
> 
>>Т.е. после 
>>gear-update-tag этот таг будет ссылаться на самый последний коммит в бранче?
> 
> 
>   Таг будет ссылаться на то, что вы ему указали.

"Что вы ему указали" можно понимать по разному ;) Я поначалу понял так, 
что таг всегда будет указывать на последний коммит в бранче, т.е. после 
git-fetch он станет указывать на новый коммит. Эксперимент показал, что 
это не так, таг остался на старом месте. Т.о. процедура выпуска новой 
версии пакета всегда должна включать создание нового тага (если 
существующие не устраивают) и, как следствие, слияние бранча апстрима и 
бранча со спеком и прочим, необходимым для сборки пакета, я правильно понял?

Еще вопрос терминологический: у меня есть 2 бранча, которые показывает 
git-branch - master (из апстрима) и srpms (со спеком и т.д.), как они 
соотносятся с бранчами в исходном коде dbmail, отчего их я вижу только в 
выводе git-show-ref? В терминах git это уже не бранчи?

И еще вопрос: в каких случаях нужно не забывать про gear-update-tag, что 
именно он делает? Из мана я этого не понял :(

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

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
>>>>Если такой вариант имеет место -- то просто создавайте тэги в нужных
>>>>вам местах. Или, как вариант -- в нужных местах создавайте тег с
>>>>постоянным именем (через "git-tag -f -a -m 'dbmail 2.2.4.x for rpmbuild'
>>>>dbmail/2.2.4-rpm XXXXX"), и неважно, что это будут разные коммиты (если
>>>>про gear-update-tag не забывать).
>>>
>>>
>>>Второй вариант не совсем понял. Что такое ХХХХХ? Имя бранча?
>>
>>
>>  То что вам надо: это может быть хеш коммита, имя бранча и, по моему --
>>существующий таг (здесь могу ошибаться).
>>
>>
>>
>>>Т.е. после 
>>>gear-update-tag этот таг будет ссылаться на самый последний коммит в бранче?
>>
>>
>>  Таг будет ссылаться на то, что вы ему указали.
> 
> 
> "Что вы ему указали" можно понимать по разному ;) Я поначалу понял так, 
> что таг всегда будет указывать на последний коммит в бранче, т.е. после 
> git-fetch он станет указывать на новый коммит. Эксперимент показал, что 
> это не так, таг остался на старом месте.

  Что и следовало ожидать: т. к. тег -- это метка соответствующего
коммита, то он не должен меняться автоматически.

> Т.о. процедура выпуска новой 
> версии пакета всегда должна включать создание нового тага (если 
> существующие не устраивают) и, как следствие, слияние бранча апстрима и 
> бранча со спеком и прочим, необходимым для сборки пакета, я правильно понял?

  Да.

> 
> Еще вопрос терминологический: у меня есть 2 бранча, которые показывает 
> git-branch - master (из апстрима) и srpms (со спеком и т.д.), как они 
> соотносятся с бранчами в исходном коде dbmail, отчего их я вижу только в 
> выводе git-show-ref? В терминах git это уже не бранчи?

  git-branch считает бранчами только расположенное в .git/refs/heads/.

> 
> И еще вопрос: в каких случаях нужно не забывать про gear-update-tag, что 
> именно он делает? Из мана я этого не понял :(

  При любых изменениях затрагивающих таг-метку.

  gear-update-tag управляет описаниями тагов, сохранёнными .gear-tags/*.
(Сама gear использует не таги, а содержимое .gear-tags/.)

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Eugene Prokopiev]

>>И еще вопрос: в каких случаях нужно не забывать про gear-update-tag, что 
>>именно он делает? Из мана я этого не понял :(
> 
> 
>   При любых изменениях затрагивающих таг-метку.
> 
>   gear-update-tag управляет описаниями тагов, сохранёнными .gear-tags/*.
> (Сама gear использует не таги, а содержимое .gear-tags/.)

Из сказанного следует, что gear не увидит только что созданный таг до 
gear-update-tag, я прав?

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

Re: [devel] tar.gz в .gear-rules из другого git-репозитария

[Aleksey Avdeev]

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

Eugene Prokopiev пишет:
>>>И еще вопрос: в каких случаях нужно не забывать про gear-update-tag, что 
>>>именно он делает? Из мана я этого не понял :(
>>
>>
>>  При любых изменениях затрагивающих таг-метку.
>>
>>  gear-update-tag управляет описаниями тагов, сохранёнными .gear-tags/*.
>>(Сама gear использует не таги, а содержимое .gear-tags/.)
> 
> 
> Из сказанного следует, что gear не увидит только что созданный таг до 
> gear-update-tag, я прав?

  Да.

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]