[devel] git question.

[devel] git question.

[Denis Medvedev]

Добрый день!
Какая правильная процедура поднятия версии при работе в 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изифу были благополучно выкинуты и заменены новой версией файлов!
Что я не так делаю? Как правильно?
   С уважением
   Денис Медведев

Re: [devel] git question.

[Damir Shayhutdinov]

> Какая правильная процедура поднятия версии при работе в 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изифу были благополучно выкинуты и заменены новой версией файлов!
> Что я не так делаю? Как правильно?

Правильнее было бы сделать ветку типа upstream. В нее распаковать 1.0,
закоммитить. Потом ее смержить в мастер, а там внести свои сизифные
изменения.

При выходе 2.0 перейти в ветку upstream.  Там распаковать 2.0,
закоммитить. Дальше смержить в мастер.

Re: [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).

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

Re: [devel] git question.

[Andrew V. Stepanov]

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)

Если в распакованом, тогда убедиться что в исходном дереве нету пустых
каталогов.


--
 stanv -- http://andrusha.googlepages.com

Re: [devel] git question.

[Dmitriy M. Maslennikov]

18 декабря 2008 г. 14:22 пользователь Alexey Morozov
<morozov_ml@ngs.ru> написал:
> 5. Что касается собственно пакетирования, то здесь возможны нюансы. Совсем
> страшный способ заключается в том, что для spec'а, .gear-rules и прочего
> сугубо мэнтейнерского хозяйства делается _отдельная_ ветка (назовём её srpm),
> не связанная поначалу ни c одной из существующих веток (как это сделать -
> вопрос отдельный).
Можно подробнее об этом отдельном вопросе?

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] git question.

[Led]

On Thursday 18 December 2008 13:43:12 Dmitriy M. Maslennikov wrote:
> 18 декабря 2008 г. 14:22 пользователь Alexey Morozov
>
> <morozov_ml@ngs.ru> написал:
> > 5. Что касается собственно пакетирования, то здесь возможны нюансы.
> > Совсем страшный способ заключается в том, что для spec'а, .gear-rules и
> > прочего сугубо мэнтейнерского хозяйства делается _отдельная_ ветка
> > (назовём её srpm), не связанная поначалу ни c одной из существующих веток
> > (как это сделать - вопрос отдельный).
>
> Можно подробнее об этом отдельном вопросе?

http://github.com/jwiegley/git-scripts/tree/master/git-empty-branch

Только в таком виде он опасен. Надо бы в него добавить проверку на наличие 
аргумента (имя бранча) и убедится, что такого бранча ещё не существует. Ну и
git commit --allow-empty -m "..."
добавить в конце.

-- 
Led

Re: [devel] git question.

[Slava Semushin]

18 декабря 2008 г. 17:22 пользователь Alexey Morozov
<morozov_ml%ngs.ru> написал:
[...]
> 5.7. Не забываем сказать gear-update-tag -a

Кто бы ещё описал что делает эта программа и в каких случаях/схемах
использования gear она используется..

Она нужна только когда патчи в отдельных бранчах и генеряться
автоматически? Или и для обычных репозиториев, созданных с помощью
gear-srpmimport годится?

> 5.8. Коммиттим
>
> Собственно, всё, можно говорить
>
> gear --rpmbuild --
> rpmbuild -bs --nodeps --define "_srcrpmdir  /home/alex/RPM/hsh/queue/"

gear-rpm -bs --nodeps --define "_srcrpmdir  /home/alex/RPM/hsh/queue/"
Кажется это полный эквивалент, только более короткий и запоминабельный.


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] git question.

[Vladimir V. Kamarzin]

>>>>> On 18 Dec 2008 at 23:59 "SS" == Slava Semushin writes:

SS> 18 декабря 2008 г. 17:22 пользователь Alexey Morozov
SS> <morozov_ml%ngs.ru> написал:
SS> [...]
>> 5.7. Не забываем сказать gear-update-tag -a
SS> Кто бы ещё описал что делает эта программа и в каких случаях/схемах
SS> использования gear она используется..

http://www.altlinux.org/Gear/tags и мана недостаточно для понимания?

-- 
vvk

Re: [devel] git question.

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

On Thu, Dec 18, 2008 at 01:03:17PM +0300, Denis Medvedev wrote:
> Какая правильная процедура поднятия версии при работе в git?
> У меня был xxx-1.0.tar.gz 
> Я его залил в гит, помучал(коммиты есть), опакетил для сизифа.
> Вышел xxx-2.0.tar.gz
> Я попробовал сделать следующее:
> git-branch 2.0

Бранч надо создавать от того коммита, который содержал неизменённые
исходники предыдущей версии.  Т.е., теперь придётся найти этот коммит
(например, в gitk), после чего выполнить

  git checkout -b upstream $commit_with_old_version

Далее обновить исходники (например, через gear-update), закоммитить
изменения, после чего

  git checkout master
  git merge upstream

При следущих обновлениях можно просто добавлять новые версии в бранч
upstream и мержить в master.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]