Grigory Batalov пишет: > On Mon, 27 Nov 2006 18:15:24 +0300 > Aleksey Avdeev wrote: > > >>>>Мне кажется, удобнее исправлять исходники непосредственно в git, >>>>скажем, в бранче devel, а не обновлять от версии к версии файлы >>>>.patch. >>> >>> >>>Тогда возникает вопрос, что делать при обновлении до новой версии. >>>Естественный для git вариант - объединить изменения с новой версией >>>через git-pull (т.е., merge), но при этом результат в общем случае уже >>>не представляется в виде набора патчей - можно сделать только один >>>общий патч от оригинальной версии к модифицированной. Чтобы получить >>>какое-то одно изменение в виде патча к текущей версии, придётся >>>выполнять, например, git-cherry-pick в отдельной временной ветке >>>(тащить его в историю пакета при таком способе работы бессмысленно - >>>оно там уже есть, возможно, с исправлениями, внесёнными в ходе >>>разрешения конфликтов при merge; единственная причина делать это - >>>необходимость подготовки патча для передачи, например, в upstream). >>> >>>Кстати, можно завести не один бранч devel, а несколько, куда разносить >>>изменения, относящиеся к разным по смыслу исправлениям. >> >> +1, особенно -- если деление по бранчм осмысленное. > > > Теперь я понял, зачем у тебя в cks.git столько бранчей =) Там бранчи 3x классов: 1. "Технические" -- относительно независимые части пакета, могущие иметь _отельную_ от остальных частей историю. Это сам спек, alt`специфичные конфиги, патчи и пр.... Общие свойство: апстрим ими не занимается (точнее -- ими могут заниматься несколько независимых апстримов). Формальный признак: отдельная тег %source*/%patch* в спеке. 2. Бранчи для генерации патчей (на основе тегов). 3. Технологический клей. Это такие вещи как .gear-rules и, в случаи cks.git, git2patch.sh. Не смотря на то, что все эти сущности в конечном итоге и создают пакет, но жить и развиваться они могут по разным законам. Думаю, что держать их обособленными -- нелишне, особенно если инструмент обеспечит прозрачность работы при таком делении. -- С уважением. Алексей.