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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 From: Alexey Morozov To: devel@lists.altlinux.org Date: Thu, 18 Dec 2008 17:22:49 +0600 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200812181722.49700.morozov_ml@ngs.ru> X-Anti-Virus: Kaspersky Anti-Virus for Sendmail with Milter API 5.6.20, bases: 20081113 #1383159, check: 20081218 clean Subject: Re: [devel] git question. X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.10b3 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: Thu, 18 Dec 2008 11:22:01 -0000 Archived-At: List-Archive: List-Post: 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). С уважением, Алексей Морозов