From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Virus-Scanned: amavisd-new at localhost Message-ID: <468C871A.4060104@solin.spb.ru> Date: Thu, 05 Jul 2007 09:52:26 +0400 From: Aleksey Avdeev User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; ru-RU; rv:1.8.1.2pre) Gecko/20070119 MultiZilla/1.8.3.0a SeaMonkey/1.1 MIME-Version: 1.0 To: ALT Devel discussion list References: <20070704194402.GB25980@solemn.turbinal> In-Reply-To: <20070704194402.GB25980@solemn.turbinal> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Subject: Re: [devel] zsh and git X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2007 06:05:41 -0000 Archived-At: List-Archive: List-Post: 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, написанный на питоне. > Но не смотрел его как следует. -- С уважением. Алексей.