[devel] zsh and git
Alexey Tourbin
=?iso-8859-1?q?at_=CE=C1_altlinux=2Eru?=
Пт Июл 6 12:55:32 MSD 2007
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. Патч будет большим и ценность
такого патча будет низкой.
> Не вижу в этом проблемы. У меня есть такой забавный пакетик faketime.
> В нём кода на несколько килобайт, но он использует gnulib на несколько
> мегабайт. Я поместил gnulib на другой бранч (у gnulib'а upstream'ный
> исходный код в git'е), поставил тэг, который время от времени передвигаю.
И что, ты делаешь фиктивный merge бранча gnulib, который не добавляет
файлов в основное дерево, только для того, чтобы получить общего предка,
чтобы создавался тарболл gnulib в .gear-rules? "Это какой-то позор." :)
> > В общем, кумулятивный патч из 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)
всё равно нельзя.
> > Кроме того, кумулятивный патч не слишком-то решает проблемы. Во-первых,
> > он всё же не слишком хорошо удовлетворяет GPL 2a.
> Почему?
Строго говоря, GPL 2a требует вносить изменения в сами файлы при каждом
измнении кода (т.е. указывать автора+дату+краткое описание). Т.е. типа
cvs $Log$. Это никогда не делалось, но хотя бы по названию отдельного
патча обычно можно было установить откуда он взялся и, соответственно,
кто его написал. Если в кумулятивном патче содержатся изменения разных
авторов, то уже нельзя непосредственно установить какой кусок кем был
написан (не говоря уж о дате).
В GPLv3 это требование по форме несколько ослаблено, так что не знаю,
стоит ли считать его принципиальным.
> > Я подумал и пришел к выводу, что git не очень-то хорошо подходит для
> > поддержки нескольких "логически нарезанных" патчей. Хранить патчи
> > отдельно в таком случае выходит проще, чем думать, как орагинзовать
> > бранчи и как их потом вливать друг в друга.
> >
> > Проблема с git'ом вот какая. Мы сделали измнение относительно версии1.
> > Потом мы делаем pull версии2. merge не проходит из-за конфликта с
> > изменением. Мы вручную правим конфликт. Теперь информаци о том, что
> > представляет из себя изменение относительно версии2, частично потерялась
> > (оно похоронено в ручном разруливании конфликта). То есть уже нельзя
> > логически однозначно восстановить патч для версии2.
>
> Можно сделать rebase, заново разрулить конфликты и получить патчи,
> сделанные для новой версии, но. Это другая модель разработки, обычно
> не очень удобная, поскольку утрачивается история.
Можно делать вот как: не допускать конфликтных мержев (если они
задеваются локальными изменениями в коде). Если мерж оказывается
конфликтным, то нужно сначала откатить (revert) те изменения, из-за
которых получается конфликт. Потом сделать бесконфликтный мерж.
А потом заново эти патчи накатить, уже разруливая конфликт.
При таком раскладе получается, что любое локальное изменение всегда можно
откатить, как если бы можно было отключать патчи в spec-файле. Впрочем,
если патчи между собой конфликтуют, то отключать их в spec-файле просто
так всё равно нельзя. В этом случае получается то же самое, только git
лучше.
В общем, git довольно дубовая система, она не решает тонких проблем,
а просто не обращает на эти проблемы внимания. Впрочем, всё равно никто
не знает, как надо "по-хорошему" решать эти "тонкие проблемы". Вроде в
darcs какие-то идеи на этот счет были.
> > В идеале нужна такая система, которая позволяет "логически
> > восстанавливать" патч для каждой версии, а не хоронить конфликты
> > под мёржами.
> >
> > ПОСЛЕ КОНФЛИКТНОГО МЁРЖА ПАТЧ УЖЕ НЕЛЬЗЯ ОТКАТИТЬ РЕВЁРТОМ,
> > правильно я понимаю?
>
> Можно, при этом, скорее всего, придётся разрулить новый конфликт.
Ну вот получается, что в ряде случаев патчи в src.rpm пакете отключать
проще, чем откатывать "старые" локальные изменения в git'е.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?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/81f7f88f/attachment-0001.bin>
Подробная информация о списке рассылки Devel