[devel] zsh and git
Michael Shigorin
=?iso-8859-1?q?mike_=CE=C1_osdn=2Eorg=2Eua?=
Ср Июл 4 23:44:02 MSD 2007
Поступила такая "малява".
----- 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, написанный на питоне.
Но не смотрел его как следует.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?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/20070704/ef6c204c/attachment-0001.bin>
Подробная информация о списке рассылки Devel