CODEWITHSUNDEEP
linuxgit
jbarlow
jbarlow

Reputation: 1518

Git/Linux: What is a good strategy for maintaining a Linux kernel with patches from multiple Git repositories?

I am maintaining a custom Linux kernel which is comprised of merged changes from a variety of sources. This is for an embedded system.

The chip vendor we are working with releases a board support package as a changes against a mainline kernel (2.6.31). I have since made changes to support our custom hardware, and also merged with the stable (2.6.31.y) kernel releases. I've also merged in bug fixes for a specific file system driver that we use, sometimes before the changes make it to the mainline kernel.

I haven't been very systematic about how I have managed the various contributing sources and my own changes. If the change was large I tended to merge; if it was small I tended to rebase the third party changeset on to my own. Generally speaking merge conflicts are rare, since most of my work affects drivers that are not in the mainline kernel anyway.

I'm wondering if there is a better way to manage all of this. One concern is that my changes are mixed in with merges. The history might look something like:

2.6.31 + board support package + my changes (1) + 2.6.31.12 changes + my changes (2) + file system driver update + my changes (3) + 2.6.31.14 changes + my changes(4) + ....

It worries me a bit that my changes are mixed in, sometimes on the other side of merges. Is there a better way to do this? In particular, is there a way to do this that will make life easier when I switch to a newer kernel?

Upvotes: 1

Views: 1355

Answers (2)

sehe
sehe

Reputation: 392999

I think the generally accepted best policy is (a) patch sets (b) topic branches

Topic branches are essentially the same but are regularly rebased onto mainline. Topgit is a known tool that makes handling topic branches 'easier' if you have a lot of them. Otherwise: plan ahead and limit the number of branches

Upvotes: 0

Jonathan
Jonathan

Reputation: 13624

I don't think it will be easy to clean up your current set-up, unless your history is reasonably short, but I would suggest this:

Set up a Master repository which has remotes set up for each of the other places that your code comes from -- the mainline kernel, patches, ...

Keep a separate branch specifically for the updates from your driver supplier.

When you fetch, the updates will not mess with your branches.

When you are ready to merge, merge into some kind of "release" branch. The idea is to keep each source separate from the others, except when it needs to be merged in. Base your changes off of this branch, merging/rebasing as necessary.

Here's a quick diagram which I hope is helpful:

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

With so many branches, it is difficult to diagram effectively, but I hope that gives you an idea of what I mean. release holds the official code for your system, you holds your own modifications, driver holds patches from the driver supplier, patches holds patches from some other repo, and mainline is the mainline kernel. Everything gets merged into release, and you base your changes off of release but only interact by merging in each direction, not making changes directly to release.

Upvotes: 2

Related Questions