Git / Linux: Какова хорошая стратегия для поддержки ядра Linux с патчами из нескольких репозиториев Git?

Question

Я поддерживаю собственное ядро ​​Linux, которое состоит из объединенных изменений из различных источников.Это для встроенной системы.

Производитель чипа, с которым мы работаем, выпускает пакет поддержки платы в качестве изменений по отношению к основному ядру (2.6.31).С тех пор я внес изменения в поддержку нашего нестандартного оборудования, а также объединился со стабильными (2.6.31.y) выпусками ядра.Я также включил исправления ошибок для конкретного драйвера файловой системы, который мы используем, иногда до того, как изменения вносятся в основное ядро.

Я не очень систематически относился к тому, как я управлял различными участниками.источники и мои собственные изменения.Если изменение было большим, я имел тенденцию сливаться;если он был маленьким, я старался заменить сторонний набор изменений на свой собственный.Вообще говоря, конфликты слияний встречаются редко, так как большая часть моей работы затрагивает драйверы, которых нет в основном ядре.

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

2.6.31 + пакет поддержки платы + мои изменения (1) + 2.6.31.12 изменения + мои изменения (2) + обновление драйвера файловой системы + мои изменения (3) + 2.6.31.14 изменения + мои изменения (4) + ....

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

Answer 1

Я не думаю, что будет легко очистить вашу текущую настройку, если ваша история не достаточно коротка, но я бы посоветовал это:

Настройка главного репозитория, в котором настроены удаленные устройствадля каждого из других мест, откуда приходит ваш код - основного ядра, исправлений, ...

Храните отдельную ветку специально для обновлений от вашего поставщика драйверов.

Когда вы выбираетеобновления не будут связываться с вашими ветками.

Когда вы будете готовы к слиянию, объединяйтесь в какую-то ветку "release".Идея состоит в том, чтобы хранить каждый источник отдельно от других, за исключением случаев, когда его необходимо объединить. Основывайте свои изменения вне этой ветви, объединяя / перебирая при необходимости.

Вот краткая диаграмма, которая, я надеюсь, будет полезна:

mainline-\----------\-------------------------------\
          \           \              /you---\---/-/  \
           \release----\-/---/----/-/--------\-/ /  --\-----
patches-----------------/---/    /              /
                                /              /
driver-------------------------/--------------/

При таком количестве ветвей сложно эффективно построить диаграмму, но я надеюсь, что это даст вам представление о том, что я имею в виду.release содержит официальный код вашей системы, you содержит ваши собственные модификации, driver содержит исправления от поставщика драйверов, patches содержит исправления из какого-либо другого репозитория, а mainline является основным ядром.Все объединяется в release, и вы основываете свои изменения на release, но взаимодействуете только путем объединения в каждом направлении, не внося изменений непосредственно в release.

Answer 2

Я думаю, что общепринятая лучшая политика (а) наборы патчей (б) тематические ветки

Тематические ветки по сути одинаковы, но регулярно перебазируются на основную линию Topgit - это известный инструмент, который облегчает работу с ветками тем, если их много. В противном случае: планируйте заранее и ограничьте количество филиалов