Git/MergingBranches

Материал из ALT Linux Wiki

(Различия между версиями)
Перейти к: навигация, поиск
(Import from freesource.info)
(викификация, корректировка заголовка)
Строка 1: Строка 1:
-
[[Category:Devel]]
+
[[Категория:Devel]]
-
{{MovedFromFreesourceInfo|AltLinux/Sisyphus/devel/git/MergingBranches}}
+
-
== Как хранить каждый патч в отдельном бранче ==
+
== Хранение патчей в отдельных бранчах git-репозитория ==
-
''статья на основе письма raorn''
+
-
''[http://lists.altlinux.org/pipermail/sisyphus/2007-September/207264.html raorn@]''
+
-
Как вы все наверно знаете, наш mutt1.5 это такой mutt2ng-new с большим количеством "левых" патчей. Из-за такого количества каждое обновление версии превращается в изощрённую пытку для мантейнера. По идее git должен бы помочь решить подобные проблемы...
+
Как вы все наверно знаете, наш mutt1.5 это такой mutt2ng-new с большим количеством «левых» патчей. Из-за такого количества каждое обновление версии превращается в изощрённую пытку для мантейнера. По идее git должен бы помочь решить подобные проблемы…
-
Сначала я посмотрел на kernel-image. Там каждый патч живёт в отдельном бранче, перед релизом всё мержится в master. Примерно так:
+
Сначала я посмотрел на kernel-image. Там каждый патч живёт в отдельном бранче, перед релизом всё мержится в master. Примерно так:
:::  
:::  
<pre>master
<pre>master
Строка 26: Строка 23:
         | |</pre>
         | |</pre>
-
По каждому патчу конфликт разруливается сначала в patchX, потом в merge-X. При обновлении версии upstream и/или patchX приходится делать маленький закат солнца вручную с повторным разруливаением всех конфликтов. Это не ядро и патчи имеют обыкновение пересекаться во множестве мест.
+
По каждому патчу конфликт разруливается сначала в patchX, потом в merge-X. При обновлении версии upstream и/или patchX приходится делать маленький закат солнца вручную с повторным разруливаением всех конфликтов. Это не ядро и патчи имеют обыкновение пересекаться во множестве мест.
Результат этого изврата ещё некоторое время можно будет наблюдать в моём mutt1.5.git.
Результат этого изврата ещё некоторое время можно будет наблюдать в моём mutt1.5.git.
-
Есть второй способ, который посоветовал мне voins (на примере его stklos.git и [[git/WindowMaker.git|WindowMaker.git]]). upstream мержится в patchA, patchA в patchB и так далее. При этом конфликты разруливаются практически только один раз при мерже patchN-1 в patchN.
+
Есть второй способ, который посоветовал мне 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

Ссылки

 
Личные инструменты