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

[Aleksey Avdeev]

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: Вы можете дать забрать откуда либо ваш репозитарий? (Мне желательно
его увидеть, для болие осмысленной ответов.)

-- 

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


----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 481 байтов
Описание: OpenPGP digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20070402/ea970a73/attachment-0001.bin>