[devel] zsh and git

[Michael Shigorin <mike@osdn.org.ua>]

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