From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.2.5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imath.kiev.ua; s=hydra; t=1403126733; bh=cwAnrALtLV+NdYRvTN5Yh7duSkHhW7ah02rJLzNtpnA=; h=Date:From:To:Subject:References:In-Reply-To; b=cy8MDUujiV2+ajMlzs+hDk7/wHqKtVyQAW9V1S5sPqblleRfl87S3LmtrkSVG+fes MbbJpxFwObv6JA/xwGHE69kBmyUbtA3bMiuOmGFwXdHjiJI5RzUOE3xkKUNCJEibB5 kWuCBGwizBPf7hk0Zru4Km+rukPQKZJ1hnpecxa4= X-Virus-Scanned: amavisd-new at imath.kiev.ua DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imath.kiev.ua; s=hydra; t=1403126728; bh=cwAnrALtLV+NdYRvTN5Yh7duSkHhW7ah02rJLzNtpnA=; h=Date:From:To:Subject:References:In-Reply-To; b=hR469Q4K0PtiC/i8b+0KeAuHBrTwZDgTpHnIPCryoQQIq7pga5TCU44+qRaT3YrxC 6igTuryhrr4P+VZiwGV2+wSKp22NUc8G+JEzo6zm9YSdO216TT+7BS1HTqhYcwTcQB +dDxZxLkr9Ma9qd98LqbKuvdxOHp1K5PIblbx6Go= Date: Thu, 19 Jun 2014 00:28:01 +0300 From: Igor Vlasenko To: ALT Linux Team development discussions Message-ID: <20140618212801.GA5120@dad.imath.kiev.ua> References: <20140617225903.GA27933@dad.imath.kiev.ua> <53A12CB4.8000907@altlinux.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53A12CB4.8000907@altlinux.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [devel] =?utf-8?b?R2VhciDQuCDQstC90LXRiNC90LjQtSAgVkNTLg==?= 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 21:25:42 -0000 Archived-At: List-Archive: List-Post: On Wed, Jun 18, 2014 at 10:07:48AM +0400, Anton Farygin wrote: > git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git > v([0-9]*\.[0-9]*) local:upstream да, что-то такое я и думаю сделать в обвязках над. но, разбить этот файл на 2 части: aналог watch, скажем release-tag-filter, в котором будет только v?([0-9]*\.[0-9]*) и, скажем, .gear/upstream-remotes, в котором будет храниться информация, которую в старом формате remotes можно было записать как URL: git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git Pull: master:upstream а в формате git config --list ее можно записать как #remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* remote.origin.url=git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git branch.upstream.remote=origin branch.upstream.merge=refs/heads/upstream За день осмыслилось, что и gear-fetch не нужен, достаточно 2-х более простых утилит, gear-save-remotes и gear-restore-remotes. Зачем так важно выделить информацию о remotes в отдельный файл? чтобы сразу вдобавок к возможности отслеживания решить и другую, на мой взгляд более важную, задачу: Дать стандартный способ майнтайнерам поделиться с коллегами, как же обновлять их репозиторий. Потому что в текущем виде gear репозитории не дружественны к совместной работе. tarball-обновляемые gear репозитории дружественны, src.rpm дружественны, а VCS-обновляемые - нет. Представьте себе, что ваш обновляемый из апстримного git репозиторий какой-то добрый человек поверх обновил из tarball'а и отправил на сборку в Сизиф. Похожее чувство я испытываю, когда нужно обновить перловую зависимость, но соответствуюший пакет обновляется из VCS. Там весь пакет на 200 строчек. Я знаю, какая там версия. У меня под рукой свежий апстримный tarball. Но я не могу взять и обновить - надо рыться в VCS-помойках и искать, где этот ****ов git и затем настраивать (каждый раз!) клонированный репозиторий, и все только для того, чтобы сделать git fetch origin. И майнтайнер, который разместил свой пакет в VCS-обновляемом gear репозитории не виноват --- это дыра в дизайне gear, которая делает VCS-обновляемые gear репозитории гораздо худшим средством для _совместной_ разработки, чем src.rpm. И всего-то надо инструмент, чтобы gear репозиторий хранил в себе свои remotes. как минимум, что-то вроде gear-save-remotes и gear-restore-remotes Это удобно и NMUшникам, и основному майнтайнеру: если remotes не сохраняются, то на git.alt копии его репозиториев неполноценные, и если слетит диск, то не достаточно будет склонировать их с git.alt, придется заново тратить время на восстановление локальных настроек remotes (а если использовался git-svn, то там все вообще печально). Да и на даче / в походе удобнее - не нужно таскать с собой диски или тратить время на настройку git-клона. -- I V