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

[Igor Vlasenko]

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