Hi,

Как уже было сказано, gear не накладывает ограничений на внутреннюю
организацию git-репозитория (не считая файла с правилами).
Тем не менее, у меня есть несколько соображений о том, как более
эффективно и удобно организовывать git-репозитории, предназначенные
для хранения пакетов:

+ Одна сущность - один репозиторий.
Не стоит помещать в один репозиторий несколько разных пакетов, за
исключением случаев, когда у этих пакетов есть общий пакет-предок.
Соблюдение этого правила облегчает совместную работу над пакетом,
поскольку не перегруженный репозиторий легче клонировать и в целом
инструментарий git больше подходит для работы с такими репозиториями.
- Отрицательная сторона: несколько сложнее делать "push" и "pull" в
случае, когда репозиториев, которые надо обработать, много.  Впрочем,
push/pull в цикле выручает.

+ Несжатый исходный код.
Сжатый разными архиваторами исходный код (как правило это tarball'ы)
лучше хранить в git-репозитории в несжатом виде.  Изменение файлов,
которые помещены в репозиторий в сжатом виде, менее удобно отслеживать
штатными средствами (git-diff).  Поскольку git хранит объекты в сжатом
виде, двойное сжатие редко приводит к экономии дискового пространства.
Наконец, алгоритм, применяемый для минимизации трафика при обновлении
репозитория по протоколу git, заметно более эффективен на несжатых
данных.  
- Отрицательная сторона: поскольку некоторые виды сжатия одних и тех же
данных могут приводить к разным результатам, может уменьшиться степень
первозданности (нативности) исходного кода.

+ Распакованный исходный код.
Исходный код, запакованный tar/cpio/..., лучше хранить в git-репозитории
в распакованном виде, по тем же причинам (заметно удобнее отслеживать
изменения, существенно меньше трафик при обновлении).
- Отрицательная сторона: поскольку git из информации о владельце, правах
доступа и дате модификации файлов хранит только исполняемость файлов,
любой архив, созданный из репозитория, будет по этим параметрам отличаться
от первозданного.  Помимо потери нативности, изменение прав доступа и
даты модификации может теоретически повлиять на результат сборки пакета.
Впрочем, такие пакеты, если они будут обнаружены, всё равно надо править.

+ Аккуратный changelog.
В changelog релизного commit'а стоит включать соответствующий текст из
changelog'а пакета, как это делают утилиты gear-commit (обёртка к
git-commit, специально предназначенная для этих целей) и gear-srpmimport.
В результате можно будет получить представление об изменениях в пакете,
не заглядывая в spec-файл самого пакета.


-- 
ldv