Re: [devel] zsh and git

["Dmitry V. Levin" <ldv@altlinux.org>]

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

On Wed, Jul 04, 2007 at 11:44:02PM +0400, Alexey M. Tourbin wrote:
[...]
> Второй вопрос по организации src.rpm пакетов.  Я уже писал,
> что мне удобнее всего класть в src.rpm пакеты монолитный
> %name-%version-%release.tar.  Это не то, что люди ожидают увидеть
> внутри src.rpm пакетов.  Поэтому я также писал, что не хотел бы
> распространять такие src.rpm пакеты.

Это зависит.  Если у пакета upstream в git'е, и бранч, из которого ведётся
сборка пакета, основан не на релизах а на upstream'ном git'е, то я вижу
больше смысла пакетовать в srpm этот самый %name-%version-%release.tar,
нежели %name-%version.tar (который имеет все шансы отличаться от
релизного по составу файлов) с кумулятивным патчем.

> Промежуточный вариант -- сделать кумулятивный патч всех локальных
> измнениний с помощью .gear-rules.  Это тоже не очень удобно, особенно
> из-за того, что я собираю zsh из cvs snapshot'ов, а не официальных
> релизов (исторически сложилось так, что очень долго не было официального
> релиза с поддержкой юникода, а в cvs snapshot'ах оно неплохо работало).
> То есть каждый раз я перебираюсь на более новый cvs snapshot.
> Более того, иногда я откручиваю cvs snapshot на несколько коммитов назад,
> прежде чем делать pull (если вижу наверху потенциально проблемные
> коммиты).  Проблема тут в том, что прежде чем начать собирать snapshot
> с помощью gear, нужно заранее поставить таг на этот snapshot и внести
> этот таг в gear-tags.  А ведь я заранее не знаю, на каком именно
> snapshot'е я в конечном счете остановлюсь.

Не вижу в этом проблемы.  У меня есть такой забавный пакетик faketime.
В нём кода на несколько килобайт, но он использует gnulib на несколько
мегабайт.  Я поместил gnulib на другой бранч (у gnulib'а upstream'ный
исходный код в git'е), поставил тэг, который время от времени передвигаю.

> В общем, кумулятивный патч из gear-tags более-менее подходит только
> тогда, когда сборки строго отсчитываются от официальных релизов.

У меня другое мнение.  Если сборки отсчитываются от upstream'а в
каком-нибудь виде, в т.ч. снапшотов, то можно сделать кумулятивный патч.
Можно даже сделать 2 кумулятивных патча: от последнего релиза до
последнего снапшота, и от последнего снапшота HEAD.

> Кроме того, кумулятивный патч не слишком-то решает проблемы.  Во-первых,
> он всё же не слишком хорошо удовлетворяет GPL 2a.

Почему?

> Во-вторых, [...] люди по-прежнему хотят видеть не только оригинальный
> тарболл, но и логично нарезнные патчи, которые можно избирательно
> отключать.  Это сделать ещё сложнее.

Это гораздо лучше делать средствами GIT.  Таких людей нужно просто
отправлять на gitweb.  Перефразируя аналогию из соседнего треда, мы
разработали новый летательный аппарат не для того, чтобы потенциальный
пассажир разбирал его на металлолом.

> Я подумал и пришел к выводу, что git не очень-то хорошо подходит для
> поддержки нескольких "логически нарезанных" патчей.  Хранить патчи
> отдельно в таком случае выходит проще, чем думать, как орагинзовать
> бранчи и как их потом вливать друг в друга.
> 
> Проблема с git'ом вот какая.  Мы сделали измнение относительно версии1.
> Потом мы делаем pull версии2.  merge не проходит из-за конфликта с
> изменением.  Мы вручную правим конфликт.  Теперь информаци о том, что
> представляет из себя изменение относительно версии2, частично потерялась
> (оно похоронено в ручном разруливании конфликта).  То есть уже нельзя
> логически однозначно восстановить патч для версии2.

Можно сделать rebase, заново разрулить конфликты и получить патчи,
сделанные для новой версии, но.  Это другая модель разработки, обычно
не очень удобная, поскольку утрачивается история.

> В идеале нужна такая система, которая позволяет "логически
> восстанавливать" патч для каждой версии, а не хоронить конфликты
> под мёржами.
> 
> ПОСЛЕ КОНФЛИКТНОГО МЁРЖА ПАТЧ УЖЕ НЕЛЬЗЯ ОТКАТИТЬ РЕВЁРТОМ,
> правильно я понимаю?

Можно, при этом, скорее всего, придётся разрулить новый конфликт.


-- 
ldv

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