[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, написанный на питоне.
> Но не смотрел его как следует.

-- 

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