From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <53A12CB4.8000907@altlinux.com> Date: Wed, 18 Jun 2014 10:07:48 +0400 From: Anton Farygin Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Igor Vlasenko , devel@lists.altlinux.org References: <20140617225903.GA27933@dad.imath.kiev.ua> In-Reply-To: <20140617225903.GA27933@dad.imath.kiev.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?utf-8?b?R2VhciDQuCDQstC90LXRiNC90LjQtSBWQ1Mu?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 06:07:53 -0000 Archived-At: List-Archive: List-Post: 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 > можно будет обсудить позже, обсуждение лучше начать > с базовых вещей. >