Git/MergingBranches
Материал из ALT Linux Wiki
(Import from freesource.info) |
(викификация, корректировка заголовка) |
||
Строка 1: | Строка 1: | ||
- | [[ | + | [[Категория:Devel]] |
- | + | ||
- | == | + | == Хранение патчей в отдельных бранчах git-репозитория == |
- | + | ||
- | + | ||
- | Как вы все наверно знаете, наш mutt1.5 это такой mutt2ng-new с большим количеством | + | Как вы все наверно знаете, наш mutt1.5 это такой mutt2ng-new с большим количеством «левых» патчей. Из-за такого количества каждое обновление версии превращается в изощрённую пытку для мантейнера. По идее git должен бы помочь решить подобные проблемы… |
- | Сначала я посмотрел на kernel-image. | + | Сначала я посмотрел на kernel-image. Там каждый патч живёт в отдельном бранче, перед релизом всё мержится в master. Примерно так: |
::: | ::: | ||
<pre>master | <pre>master | ||
Строка 26: | Строка 23: | ||
| |</pre> | | |</pre> | ||
- | По каждому патчу конфликт разруливается сначала в patchX, потом в merge-X. | + | По каждому патчу конфликт разруливается сначала в patchX, потом в merge-X. При обновлении версии upstream и/или patchX приходится делать маленький закат солнца вручную с повторным разруливаением всех конфликтов. Это не ядро и патчи имеют обыкновение пересекаться во множестве мест. |
Результат этого изврата ещё некоторое время можно будет наблюдать в моём mutt1.5.git. | Результат этого изврата ещё некоторое время можно будет наблюдать в моём mutt1.5.git. | ||
- | Есть второй способ, который посоветовал мне voins (на примере его stklos.git и [[git/WindowMaker.git|WindowMaker.git]]). | + | Есть второй способ, который посоветовал мне voins (на примере его stklos.git и [[git/WindowMaker.git|WindowMaker.git]]). upstream мержится в patchA, patchA в patchB и так далее. При этом конфликты разруливаются практически только один раз при мерже patchN-1 в patchN. |
Картинко будет примерно такое: | Картинко будет примерно такое: | ||
Строка 53: | Строка 50: | ||
patchA <- upstream | patchA <- upstream | ||
patchB <- patchA | patchB <- patchA | ||
- | + | … | |
master <- patchZ | master <- patchZ | ||
Строка 64: | Строка 61: | ||
branch -d patchX-tmp | branch -d patchX-tmp | ||
patch(X+1) <- patchX | patch(X+1) <- patchX | ||
- | + | … | |
master <- patchZ | master <- patchZ | ||
Строка 87: | Строка 84: | ||
merge: patches/alt/007-krb5 patches/alt/008-Makefile | merge: patches/alt/007-krb5 patches/alt/008-Makefile | ||
merge: patches/alt/008-Makefile master</pre> | merge: patches/alt/008-Makefile master</pre> | ||
+ | |||
+ | === Ссылки=== | ||
+ | * http://lists.altlinux.org/pipermail/sisyphus/2007-September/207264.html |
Версия 08:04, 21 октября 2008
Хранение патчей в отдельных бранчах git-репозитория
Как вы все наверно знаете, наш mutt1.5 это такой mutt2ng-new с большим количеством «левых» патчей. Из-за такого количества каждое обновление версии превращается в изощрённую пытку для мантейнера. По идее git должен бы помочь решить подобные проблемы…
Сначала я посмотрел на kernel-image. Там каждый патч живёт в отдельном бранче, перед релизом всё мержится в master. Примерно так:
master * merge-C /| / * merge-B / /| / / * merge-A / / /| / / / * merge-upstream / / / /| * | | | | patchC | * | | | patchB | | * | | patchA \ \ \| | +-+-* | upstream | |
По каждому патчу конфликт разруливается сначала в patchX, потом в merge-X. При обновлении версии upstream и/или patchX приходится делать маленький закат солнца вручную с повторным разруливаением всех конфликтов. Это не ядро и патчи имеют обыкновение пересекаться во множестве мест.
Результат этого изврата ещё некоторое время можно будет наблюдать в моём mutt1.5.git.
Есть второй способ, который посоветовал мне voins (на примере его stklos.git и WindowMaker.git). upstream мержится в patchA, patchA в patchB и так далее. При этом конфликты разруливаются практически только один раз при мерже patchN-1 в patchN.
Картинко будет примерно такое:
master * |\ | * patchC | |\ | | * patchB | | |\ | | | * patchA | | | |\ | | | | * upstream | | | | |
Что делать при обновлении upstream и/или patchX?
1. upstream
patchA <- upstream patchB <- patchA … master <- patchZ
2. patchX
branch patchX-tmp upstream накладываем новый patchX в patchX-tmp patchX-tmp <- patch(X-1) patchX <- patchX-tmp branch -d patchX-tmp patch(X+1) <- patchX … master <- patchZ
3. patchX и upstream
До patch(X-1) поступаем аналогично 1., потом аналогично 2.
Автоматизация процесса
Автоматизировать процесс можно с помощью утилиты gear-merge. Утилита довольно простая. Краткий синтаксис правил описан в заголовке (vim /usr/bin/gear-merge), опции описаны в man-странице.
Вот так выглядит файл правил для мёржа на примере inn.git:
% cat .gear/merge merge: upstream patches/debian/0001-libdb-4.4 merge: patches/debian/0001-libdb-4.4 patches/alt/001-cdb merge: patches/alt/001-cdb patches/alt/002-db4 merge: patches/alt/002-db4 patches/alt/003-docs merge: patches/alt/003-docs patches/alt/004-gdbm merge: patches/alt/004-gdbm patches/alt/005-pie merge: patches/alt/005-pie patches/alt/006-2.4.2-alt merge: patches/alt/006-2.4.2-alt patches/alt/007-krb5 merge: patches/alt/007-krb5 patches/alt/008-Makefile merge: patches/alt/008-Makefile master