[devel] git question.

[Alexey Morozov]

On Thursday 18 December 2008 16:03:17 Denis Medvedev wrote:
> Добрый день!
> Какая правильная процедура поднятия версии при работе в git?
> У меня был xxx-1.0.tar.gz
> Я его залил в гит, помучал(коммиты есть), опакетил для сизифа.
> Вышел xxx-2.0.tar.gz
> Я попробовал сделать следующее:
> git-branch 2.0
> распаковал туда архив
> git-commit -a
> git-checkout master
> git-merge 2.0
> Все успешно проехало... но мои изменения-адаптации к cизифу были
> благополучно выкинуты и заменены новой версией файлов! Что я не так делаю?
> Как правильно?

Вероятнее всего, правильно примерно так:

1. есть ветка с апстримовскими сорцами, назовём её, скажем, upstream.
в неё заливаются, как есть, сорцы версии 1.0, желательно в распакованном виде.
Ставим метку (что-то типа upstream-1.0)

2. если нужны фиксы, находясь в этой точке (ветка upstream, пометка 
upstream/1.0) создаем бранч(и) для фиксов. В простейшем случае это будет 1 
бранч, в котором будут накапливаться коммиты, исправляющие апстрим: git 
checkout -b fixes. По сути, в ветке fixes будут находиться исходники в том 
состоянии, из которого Вы потом собираете rpm. Ставим соответствующую метку, 
например, fixes-1.0-alt1.

3. в момент выхода 2.0 сорцы заливаются в ветку upstream, ставится пометка 
upstream-2.0. Таким образом, git diff upstream-1.0..upstream-2.0 даст разницу 
между первой и второй версиями.

4. Далее "апгрейдим" патчи. Переходим в ветку fixes и говорим там git merge 
upstream. Разруливаем конфликты, в итоге получаем в ветке fixes "пофикшенную" 
версию upstream. Ставим соответствующую метку.

5. Что касается собственно пакетирования, то здесь возможны нюансы. Совсем 
страшный способ заключается в том, что для spec'а, .gear-rules и прочего 
сугубо мэнтейнерского хозяйства делается _отдельная_ ветка (назовём её srpm), 
не связанная поначалу ни c одной из существующих веток (как это сделать - 
вопрос отдельный). Далее делаем следующие пассы руками, головой и другими 
частями тела:

5.1. Находясь в ветке srpm говорим:
git merge -s ours --no-commit upstream-2.0 fixes-2.0 (или любой другой 
требуемой Вам версии)
5.2. Вписываем соответствующую версию в спек, желательно, непосредственно в 
поле Version:
5.2. В Source в спеке пишем %name-%version.tar.bz2 - здесь будут апстримовские 
исходники.
5.3. В Patch пишем %name-%version-alt_fixes.patch - здесь будет кумулятивный 
патч из ветки fixes. Можно сделать несколько патчей, по темам, но тогда 
придётся их описывать более аккуратно (см. ниже).
5.4. Вписываем подходящий релиз и ченджлог.
5.5. В .gear-rules пишем что-то навроде следующего:
tar.bz2: upstream- на version@:. <здесь параметры для gear, поиграйтесь с тем, 
чтобы достичь требуемого вида архива>
diff: upstream- на version@:. fixes- на version@- на release@:. <остальные параметры 
для diff>
5.6. Добавляем (git add) спек и .gear-rules
5.7. Не забываем сказать gear-update-tag -a
5.8. Коммиттим

Собственно, всё, можно говорить

gear --rpmbuild -- 
rpmbuild -bs --nodeps --define "_srcrpmdir  /home/alex/RPM/hsh/queue/"

Это, в общем, один из самых страшных способов, он позволяет напрочь разделить 
апстримовскую, "фиксящую" и  мэнтейнерскую части (в последнюю могут войти, 
например, патчи или какие-нибудь дополнительные файлы, которые интересны 
только в рамках ALTLinux).

Для тех, кому вышеперечисленное кажется сильно страшным, можно, не мудрствуя, 
после шага 4 засунуть спек непосредственно в ветку fixes и написать 
в .gear-rules:

tar.bz2:.

Но это уже на любителя.

P.S. Пишу, тыкскыть, на память, не обессудьте, если где-то надо подрихтовать. 
Но в целом - работает, "проверено на себе" (tm).

С уважением,
Алексей Морозов