если будут патчиться параллельно и сторонние исходники и ваши - вы потом запаритесь синхронизировать их меж собой: что с чем собирается, совместимость версий и т.д. лучше всё хранить в одном репозитории и иметь все сорцы, из которых собирается конечный продукт.
если это git, то можно попробовать submodule: https://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
там есть жёсткая привязка к конкретной версии.

Я использую следующее:
contribs/ - все стороние пакеты
patches/ - мои изменения стороних пакетов
сборка осуществляется с использованием Makefile, механизм прошивки зависит от железа

если будут патчиться параллельно и сторонние исходники и ваши

Не, патчатся только сторонние исходники. А собираются и наши, и чужие + наши патчи. Но твоя правда, это будет неиссякаемый источник головной боли со сменой версий сторонних исходников.

Пока что это выглядело бы вот так:

.
├── contrib
│   └── kernel-source
│       ├── 3.0.35
│       └── 3.2.0
└── project
    └── src
        └── kernel
            ├── 3.0.35
            │   ├── modules
            │   └── patches
            └── 3.2.0
                ├── modules
                └── patches

Но все это лежит в одном гит-репозитории?

Но все это лежит в одном гит-репозитории?

Да.
Тут правда есть небольшое отступление - если часть внешних компонентов входят в состав SDK от производителя, то они там и остаются, а в документации указывается версия SDK и оно, SDK, сохраняется на внутреннем сервере.

У нас в качестве такого SDK выступает связка toolchain + kernel + rootfs + bootloader, поскольку все они сильно пропатчены вендором. Но нам нужно патчить их дальше под свои нужды.

Вы не одиноки, поэтому patch-и на компоненты SDK я храню в проекте, а SDK вовне, так как оно может использоваться в нескольких проектах.

Мы делаем так

Git репозиторий со сборочными скриптами у которого субмодулями идут сторонние компоненты (ядро, rootfs, SDK и т.д.). Исходники импортированы из оригинальных тарников: git init, потом наши патчи. Таким образом крупные изменения (мажорные версии) можно в ветки выделять и история сохраняется кто что и зачем патчил. Диффы можно делать, что бывает очень полезно.

На пальцах процедура примерно такая: git init, распаковываем tar версии 1, комитим «imported foo-1.0», тегаем foo-1.0, дальше аккуратно патчим, комитим каждый по-отдельности. Вышла версия 2, возможны несовместимые изменения. Делаем бранч foo-2, откатываемся на «imported foo-1.0», удаляем все файлы (кроме .git), распаковываем foo-2.0.tar.gz, комитим «imported foo-2.0», тегаем foo-2.0, смотрим diff -t что они там понавертели, cherry-pick ещё актуальные патчи в эту ветку.

В «главном» проекте тоже можно сделать ветки, т.к. часто релизы sdk+rootfs+kernel идут вместе - чтоб удобней было переключаться.

Собственный код тоже можно сделать субмодулем, но у нас так устроено что он просто выписывается в подпапку «главного» проекта, которые всё это дело собирает.

Для автоматизации, вроде бы, есть специальные инструменты, всякие rootfs билдеры, в частности специально для embedded но мне лень было разбираться в своё время, использую собственные скрипты. Если кому-то надо могу почистить от проектно-специфичиеского и выложить на github, хотя там, наверное, не на что будет смотреть.

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

Руками поддерживать патчи неудобно - во-первых, их нужно откуда-то выгружать все равно, и разумно предположить, что это будет происходить с помощью гита. Во время сборки накладывать вручную патчи тоже мне не понравилось - обычно цели в make являются зависимостями от входных файлов, и он пересобирает все, что нужно по факту изменения этих зависимостей. А с патчами придется уже костылять.

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