[devel] zsh and git
Dmitry V. Levin
=?iso-8859-1?q?ldv_=CE=C1_altlinux=2Eorg?=
Пт Июл 6 13:08:08 MSD 2007
On Fri, Jul 06, 2007 at 12:55:32PM +0400, Alexey Tourbin wrote:
> On Fri, Jul 06, 2007 at 11:15:02AM +0400, Dmitry V. Levin wrote:
> > Это зависит. Если у пакета upstream в git'е, и бранч, из которого ведётся
> > сборка пакета, основан не на релизах а на upstream'ном git'е, то я вижу
> > больше смысла пакетовать в srpm этот самый %name-%version-%release.tar,
> > нежели %name-%version.tar (который имеет все шансы отличаться от
> > релизного по составу файлов) с кумулятивным патчем.
>
> Простой патч "не держит" как следует переименование файлов.
> У меня есть пакет напр. perl-DBI, в котором я переименовал
> Changes -> lib/DBI/Changes.pod. Патч будет большим и ценность
> такого патча будет низкой.
Значит, надо добавлять в начало патча шапку a la git diff --stat.
> > Не вижу в этом проблемы. У меня есть такой забавный пакетик faketime.
> > В нём кода на несколько килобайт, но он использует gnulib на несколько
> > мегабайт. Я поместил gnulib на другой бранч (у gnulib'а upstream'ный
> > исходный код в git'е), поставил тэг, который время от времени передвигаю.
>
> И что, ты делаешь фиктивный merge бранча gnulib, который не добавляет
> файлов в основное дерево, только для того, чтобы получить общего предка,
> чтобы создавался тарболл gnulib в .gear-rules? "Это какой-то позор." :)
Этот merge не совсем фиктивный. Я мог бы вообще вести разработку
faketime (если было бы куда её вести) на отдельном бранче, а в master'е
только мерджить бранчи.
> > > В общем, кумулятивный патч из gear-tags более-менее подходит только
> > > тогда, когда сборки строго отсчитываются от официальных релизов.
> >
> > У меня другое мнение. Если сборки отсчитываются от upstream'а в
> > каком-нибудь виде, в т.ч. снапшотов, то можно сделать кумулятивный патч.
> > Можно даже сделать 2 кумулятивных патча: от последнего релиза до
> > последнего снапшота, и от последнего снапшота HEAD.
>
> В случае с перлом очень большой апстримный патч будет от последнего
> релиза.
>
> $ git-describe 5.8
> 5.8.8-702-gb49e4f0
> $ git-diff 5.8.8..5.8 |wc -c
> 12912147
> $
>
> Такой патч ничего никому не даст, отключить его (и откатиться на 5.8.8)
> всё равно нельзя.
И это правильно.
> > > Я подумал и пришел к выводу, что git не очень-то хорошо подходит для
> > > поддержки нескольких "логически нарезанных" патчей. Хранить патчи
> > > отдельно в таком случае выходит проще, чем думать, как орагинзовать
> > > бранчи и как их потом вливать друг в друга.
> > >
> > > Проблема с git'ом вот какая. Мы сделали измнение относительно версии1.
> > > Потом мы делаем pull версии2. merge не проходит из-за конфликта с
> > > изменением. Мы вручную правим конфликт. Теперь информаци о том, что
> > > представляет из себя изменение относительно версии2, частично потерялась
> > > (оно похоронено в ручном разруливании конфликта). То есть уже нельзя
> > > логически однозначно восстановить патч для версии2.
> >
> > Можно сделать rebase, заново разрулить конфликты и получить патчи,
> > сделанные для новой версии, но. Это другая модель разработки, обычно
> > не очень удобная, поскольку утрачивается история.
>
> Можно делать вот как: не допускать конфликтных мержев (если они
> задеваются локальными изменениями в коде). Если мерж оказывается
> конфликтным, то нужно сначала откатить (revert) те изменения, из-за
> которых получается конфликт. Потом сделать бесконфликтный мерж.
> А потом заново эти патчи накатить, уже разруливая конфликт.
>
> При таком раскладе получается, что любое локальное изменение всегда можно
> откатить, как если бы можно было отключать патчи в spec-файле. Впрочем,
> если патчи между собой конфликтуют, то отключать их в spec-файле просто
> так всё равно нельзя. В этом случае получается то же самое, только git
> лучше.
>
> В общем, git довольно дубовая система, она не решает тонких проблем,
> а просто не обращает на эти проблемы внимания. Впрочем, всё равно никто
> не знает, как надо "по-хорошему" решать эти "тонкие проблемы". Вроде в
> darcs какие-то идеи на этот счет были.
Некоторые полагают, что т.н. исчисление патчей в darcs представляет в
первую очередь академический интерес:
http://article.gmane.org/gmane.comp.version-control.git/50809
> > > В идеале нужна такая система, которая позволяет "логически
> > > восстанавливать" патч для каждой версии, а не хоронить конфликты
> > > под мёржами.
> > >
> > > ПОСЛЕ КОНФЛИКТНОГО МЁРЖА ПАТЧ УЖЕ НЕЛЬЗЯ ОТКАТИТЬ РЕВЁРТОМ,
> > > правильно я понимаю?
> >
> > Можно, при этом, скорее всего, придётся разрулить новый конфликт.
>
> Ну вот получается, что в ряде случаев патчи в src.rpm пакете отключать
> проще, чем откатывать "старые" локальные изменения в git'е.
В ряде случаев при попытке отключить в srpm'е один патч перестаёт
накладываться другой патч.
Нет здесь простого решения.
--
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20070706/1c4bce0a/attachment-0001.bin>
Подробная информация о списке рассылки Devel