Re: [devel] Gear и внешние VCS.

[Anton Farygin <rider@altlinux.com>]

On 18.06.2014 02:59, Igor Vlasenko wrote:
> Засада1.  А откуда?
Это же просто. С репозитория, указанного в watch файле. Если такого нет, 
то два варианта:
1) автоматическое обновление не работает
2) добавить свой watch файл, нагуглив репозиторий апстрима.
> далее, * Засада2 *.
>
> Узнали <Где>, можем написать git getch <Где>.
> но что брать?
> git getch <Где> <что>.
>
> Есть commit с исправлениями. и в master, и cherry-pick'ed в ветвях.
> Пока думаем и гадаем, приходим к выводу, что нужна запись в недрах .gear,
> .gear/upstream[что].
Нет. нужна запись в watch файле - регексп, описывающий тэг на основании 
которого можно сделать вывод о новом релизе.
и брать надо именно тэг - не ветки же тащить с апстрима.

>
> Альтернативно, можно подождать месяц, когда будет <релиз>, а с ним <тег>,
> на который можно будет ориентироваться вместо удаленного бранча.
Эээ... а кто-то хочет собирать не-релизы ? а зачем ?
>
> И тут же плавно проваливаемся в *Засаду 3*.
>
> * Засада3 *. куда?
>
> напомню, полная команда имеет вид
> git fetch <Где> <что>:<куда>
см. ниже. На самом деле, ответ "куда" должен сформироваться из 
.gear/rules - это сильно зависит от того, как устроен обрабатываемый гит.
>
>> IV>> поэтому желательно иметь указание, в какие ветви что куда должно идти.
>> AF> честно говоря не понял, зачем это ? вижу всё так-же как и в случае с
>> тарболлом и исходниками в отдельном бранче. Ну совсем никакой разницы
>> -просто вместо gear update будет git pull. остальные этапы точно такие-же.
> Для некоторых репозиториев действительно прокатит,
> назвать ее как-то устрашающе gearobersturmbannbranch
> и сделать fetch в branch gearobersturmbannbranch:
>
> git fetch <Где> <что>:gearobersturmbannbranch
>
> но, во первых, не все .gear/rules основаны на tags,
> к примеру, в virt-viewer
> $ cat virt-viewer.git/.gear/rules
> tar: upstream:.
> и волшебная команда gear-fetch должна поддерживать
> и такие rules.
А должна ли ? почему-то rpm-uscan не поддерживает репозитории без watch 
файлов.
>
> Во вторых, для NMU с одноразовым репозиторием это еще
> прокатит, сделали NMU, а репозиторий выбросили.
>
> Но волшебная команда gear-fetch должна быть
> в первую очередь удобна для основного майнтайнера.
> У него и так есть волшебная команда git fetch origin,
> основанная на тайном знании remotes.
> Если там записано, что fetch делается в ветку upstream,
> то он делается в ветку upstream.
>
> Приходим к выводу, что нужна запись в недрах .gear,
> .gear/upstream[куда].
или в watch файле, да.

например:
git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git 
v([0-9]*\.[0-9]*) local:upstream


Кстати, это же "полечит" проблему из virt-viewer, хотя я по прежднему 
думаю что указывать ветку в качестве источника тарболла - криво.
>
> С ней волшебная команда gear-fetch отработает точно так, как
> git fetch origin.
>
> Иначе она просто намусорит: за ней придется прибрать руками,
> ветку upstream передвинуть руками, мусор gearobersturmbannbranch
> удалить.
>
> далее, ветка(ветки), записанные в .gear/upstream[куда],
> должн(ы) отражаться и в .gear/tags.
> т.е. gear-update-tag должна поддерживать .gear/upstream[куда],
> т.е. записывать в .gear/tags/list текущие позиции этих
> ветвей, чтобы их можно было восстановить, просто
> склонировав репозиторий с git.alt и запустив
> волшебную команду gear-fetch.
зачем ? эта информация не несёт никакого смысла.
>
> Так я представляю функциональность базовой
> волшебной команды gear-fetch.
>
> Функциональность волшебных надстроек над gear-fetch
> можно будет обсудить позже, обсуждение лучше начать
> с базовых вещей.
>