[devel] zsh and git

[devel] zsh and git

[Michael Shigorin]

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

Поступила такая "малява".

----- Forwarded message from jiin <newsdispute@opennet.ru> -----

Date: Thu, 28 Jun 2007 08:59:25 +0600 (YEKST)
From: jiin <newsdispute@opennet>
To: mike@osdn
Subject: Релиз ALT Linux 4.0.1 Server

Новое сообщение от 'jiin' <!sgau@email> в форуме 'Разговоры, обсуждение новостей'
Посмотреть: http://www.opennet.ru/openforum/vsluhforumID3/37729.html#17
Тема: Релиз ALT Linux 4.0.1 Server

[...]
Кстати интересный бажок такой нашёл. zsh нормально не дополняет по ssh
имена хостов. В багзилле запись от 2005 года что исправлено и используется
_known_hosts. Так вот по ip оно дополнять не хотело. А в апстриме в _hosts было
поправлено по этому поводу в районе 4.3.0 или 4.3.1. И вот только в альтовом
zsh нормально не работает zstyle ':completion:*:hosts' use-ip 1 . И что самое
интересное изучение srpm мало помогло - патчей там не было. И только изучение
http://www.sisyphus.ru/srpm/zsh/patches помогло понять что есть
zsh-4.3.0-alt-ssh-known_hosts.patch - вот такой патч. И убрав его все пошло как
по маслу.
[...]

-----------------------------------------------------------
Ответить: http://www.opennet.ru/post/vsluhforumID3/37729/17/

----- End forwarded message -----


Тут есть два вопроса.

Первый вопрос по дополнению ip-адресов, raorn только что помог мне его
решить.

Второй вопрос по организации src.rpm пакетов.  Я уже писал,
что мне удобнее всего класть в src.rpm пакеты монолитный
%name-%version-%release.tar.  Это не то, что люди ожидают увидеть
внутри src.rpm пакетов.  Поэтому я также писал, что не хотел бы
распространять такие src.rpm пакеты.

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

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

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

Я подумал и пришел к выводу, что git не очень-то хорошо подходит для
поддержки нескольких "логически нарезанных" патчей.  Хранить патчи
отдельно в таком случае выходит проще, чем думать, как орагинзовать
бранчи и как их потом вливать друг в друга.

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

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

ПОСЛЕ КОНФЛИКТНОГО МЁРЖА ПАТЧ УЖЕ НЕЛЬЗЯ ОТКАТИТЬ РЕВЁРТОМ,
правильно я понимаю?

Я видел какой-то stgit, написанный на питоне.
Но не смотрел его как следует.

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

Re: [devel] zsh and git

[Aleksey Avdeev]

Michael Shigorin пишет:
...
> 
> Второй вопрос по организации src.rpm пакетов.  Я уже писал,
> что мне удобнее всего класть в src.rpm пакеты монолитный
> %name-%version-%release.tar.  Это не то, что люди ожидают увидеть
> внутри src.rpm пакетов.  Поэтому я также писал, что не хотел бы
> распространять такие src.rpm пакеты.
> 
> Промежуточный вариант -- сделать кумулятивный патч всех локальных
> измнениний с помощью .gear-rules.  Это тоже не очень удобно, особенно
> из-за того, что я собираю zsh из cvs snapshot'ов, а не официальных
> релизов (исторически сложилось так, что очень долго не было официального
> релиза с поддержкой юникода, а в cvs snapshot'ах оно неплохо работало).
> То есть каждый раз я перебираюсь на более новый cvs snapshot.
> Более того, иногда я откручиваю cvs snapshot на несколько коммитов назад,
> прежде чем делать pull (если вижу наверху потенциально проблемные
> коммиты).  Проблема тут в том, что прежде чем начать собирать snapshot
> с помощью gear, нужно заранее поставить таг на этот snapshot и внести
> этот таг в gear-tags.  А ведь я заранее не знаю, на каком именно
> snapshot'е я в конечном счете остановлюсь.

  Таг можно переставлять (git-tag -f ...), тогда gear-update-tag
достаточно. (Если я правельно понял данный кусок проблемы.)

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

  Это причина, почему генерирую патчи из бранчей, в своих пакетах.

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

-- 

С уважением. Алексей.

Re: [devel] zsh and git

[Michael Shigorin]

On Wed, Jul 04, 2007 at 11:44:02PM +0400, Alexey Tourbin wrote:
> Поступила такая "малява".

Лёш, я ценю твоё чуйство юмора, но pls не вводи людей
в заблуждение.  Если предпочитаешь форварды баунсам,
так и скажи, вторым будешь.

> ----- Forwarded message from jiin -----
> Тут есть два вопроса.
> 
> Первый вопрос по дополнению ip-адресов, raorn только что помог
> мне его решить.
> 
> Второй вопрос по организации src.rpm пакетов.  Я уже писал,
> что мне удобнее всего класть в src.rpm пакеты монолитный
> %name-%version-%release.tar.  Это не то, что люди ожидают увидеть
> внутри src.rpm пакетов.  Поэтому я также писал, что не хотел бы
> распространять такие src.rpm пакеты.

Собсно см. тред рядом (srpm -> gear); аналогично.

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

Вот именно эта проблема у меня и наблюдается.

> Я подумал и пришел к выводу, что git не очень-то хорошо
> подходит для поддержки нескольких "логически нарезанных"
> патчей.  Хранить патчи отдельно в таком случае выходит проще,
> чем думать, как орагинзовать бранчи и как их потом вливать друг
> в друга.

Думал посмотреть на quilt, но пока сам не добрался и кого
расспросить -- тоже не наблюдаю.  Оно будто под работу с патчами
заточено.

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

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] zsh and git

[Alexey I. Froloff]

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

* Michael Shigorin <mike@> [070705 11:08]:
> > Поступила такая "малява".
> Лёш, я ценю твоё чуйство юмора, но pls не вводи людей
> в заблуждение.  Если предпочитаешь форварды баунсам,
> так и скажи, вторым будешь.
А мне вот тоже не очень приятно читать таких как jiin.
Супер-пупер крутые спецы, которые точно знают как не надо делать,
но сами ничего делать не хотят ("с багзиллой не дружу, а доку
читать лень").  Или просто не умеют?

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] [JT] zsh and git

[Michael Shigorin]

On Thu, Jul 05, 2007 at 11:46:22AM +0400, Alexey I. Froloff wrote:
> > > Поступила такая "малява".
> > Лёш, я ценю твоё чуйство юмора, но pls не вводи людей
> > в заблуждение.  Если предпочитаешь форварды баунсам,
> > так и скажи, вторым будешь.
> А мне вот тоже не очень приятно читать таких как jiin.

Уй, мадам... просто ещё один человек из команды _не любит_
bounce.  Я и минимум ещё один другой человек их _предпочитают_,
поскольку так лучше архивируется и не ломаются подписи.

Извини, что побеспокоил тебя, мне показалось интересным
всего-то zsh -fx в том сообщении.

> Супер-пупер крутые спецы, которые точно знают как не надо
> делать, но сами ничего делать не хотят ("с багзиллой не дружу,
> а доку читать лень").  Или просто не умеют?

Судя по тому, как человек идентифицировал проблему с UTF-8
в нашем screen, на что mouse@ сделал удивлённое лицо (тривиальный
патч привёл к неприятному багу неочевидным образом) -- я скорее
был бы рад видеть его в team.

Кстати, с homepage нашей багзилы до сих пор отсутствует ссылка
хотя бы на http://www.freesource.info/wiki/BugzillaMiniHowto
и доки, которую было бы лень читать, попросту нет.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] zsh and git

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] zsh and git

[Alexey Tourbin]

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

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'е.

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

Re: [devel] zsh and git

[Dmitry V. Levin]

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

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

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

Re: [devel] zsh and git

[Alexey Tourbin]

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

On Fri, Jul 06, 2007 at 01:08:08PM +0400, Dmitry V. Levin wrote:
> > В общем, git довольно дубовая система, она не решает тонких проблем,
> > а просто не обращает на эти проблемы внимания.  Впрочем, всё равно никто
> > не знает, как надо "по-хорошему" решать эти "тонкие проблемы".  Вроде в
> > darcs какие-то идеи на этот счет были.
> 
> Некоторые полагают, что т.н. исчисление патчей в darcs представляет в
> первую очередь академический интерес:
> http://article.gmane.org/gmane.comp.version-control.git/50809

Я некоторое время назад запойно изучал хаскель, но так и не понял,
как работает этот darcs.

Вот типичное требование, которому git не удовлетворяет:

	Must support partial integration of changes between branches,
	at the file level. This is a requirement, not a nice-to-have,
	brought about by how perl development is done.

http://www.nntp.perl.org/group/perl.perl5.porters/2007/07/msg126948.html

Это пишет maintainer perl-5.8.x.

То есть "частичный мёрж" сделать нельзя, в смысле никакой метаинформации
о таком мерже не сохранится.  Информация в коммите о cherry-pick по сути
метаинформацией не является.  В случае с перлом разработка устроена так,
что нужно уметь отвечать на вопрос: какие изменения из бранча 5.9 влиты
в бранч 5.8 полностью ИЛИ частично?  Какие ещё не влиты?  Какие были
просмотрены и решили что вливать не будем?  Бранчи 5.9 и 5.8 никогда
не сойдутся.

Гит провоцирует обратную схему: багфиксы делать только в бранче 5.8,
а время от времени полностью вливать бранч 5.8 в бранч 5.9.

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

Re: [devel] zsh and git

[Dmitry V. Levin]

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

On Sat, Jul 21, 2007 at 11:46:34PM +0400, Alexey Tourbin wrote:
[...]
> http://www.nntp.perl.org/group/perl.perl5.porters/2007/07/msg126948.html
> 
> Это пишет maintainer perl-5.8.x.
> 
> То есть "частичный мёрж" сделать нельзя, в смысле никакой метаинформации
> о таком мерже не сохранится.  Информация в коммите о cherry-pick по сути
> метаинформацией не является.  В случае с перлом разработка устроена так,
> что нужно уметь отвечать на вопрос: какие изменения из бранча 5.9 влиты
> в бранч 5.8 полностью ИЛИ частично?  Какие ещё не влиты?  Какие были
> просмотрены и решили что вливать не будем?  Бранчи 5.9 и 5.8 никогда
> не сойдутся.
> 
> Гит провоцирует обратную схему: багфиксы делать только в бранче 5.8,
> а время от времени полностью вливать бранч 5.8 в бранч 5.9.

Однако linux kernel явно в эту схему не укладывается;
ветки 2.6.N и 2.6.N+1 тоже никогда не сойдутся.

И тем не менее там используют git. :)


-- 
ldv

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