[Devel] Миграция в Git или из недавнего про OpenVZ

[Vitaly Lipatov]

В сообщении от Понедельник 15 августа 2011 Alexander Morozov написал(a):
> >  Вот, что я помню из этой задачи:
> >  Мы храним изменения в двух ветках: в одной правим по "живому", начиная
> >  с первых этапов разработки, в другой наши изменения всегда доступны
> >  поверх последних изменений в апстриме. При этом история наших патчей
> >  определённым образом сохраняется. Дальше деталей я не помню.
> 
> Помню когда-то обсуждался переход на новый способ хранения кода открытой
> части WINE на Etersoft. Была идея сделать так, чтобы в репозитории хранилось
> следующее:
...


У меня тут создался ещё один вариант описания:

В репозитории создаётся несколько веток
1. upstream (неизменённая)
2. rebase (где наши патчи всегда сверху)
3. history - она же непрерывная (куда отражается в виде коммита каждое 
изменение ветки 2)
4. patches - ветка с нашими патчами

Схема такая
1. в ветке 1 появляется новый коммит
2. делаем rebase ветки 2, чтобы добавить новый коммит, оставив наши патчи 
сверху
3. делаем diff между новым состоянием ветки 2 и предыдущим, получаем коммит, 
который добавляем в ветку 3

Ветка 4, по сути, просто хранит результат git format-patch для наших коммитов 
в ветке 2

Суть в том, что ветка 3 получается непрерывной, там сохраняется история, 
последовательно добавляются коммиты. Её можно использовать для сборки пакетов 
и для публикации

Получившийся коммит в ветке 3 будет не копией коммита из апстрима и лишь его 
подобием. При этом возможно использовать описание оригинального коммита, ведь 
подобный коммит будет вносить те же изменения.

-- 
С уважением,
Виталий Липатов
Россия, Санкт-Петербург. www.etersoft.ru
GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!