How to use git for Linux kernel development ?

Hi everybody,

my company decided to port the Linux kernel to custom hardware. As we need a repository for the sources, I thought I would give git a try. The man pages and tutorials are quite helpful to understand the git commands, but none of the documentation I found has been able to answer my (not so simple) question : given my use cases, how do I use git ?

Here are the use cases.

I need to port the Linux kernel to custom hardware. This means fixing bugs in the kernel, adding new features and new device drivers. Some of the modifications I make (bug fixes) will be pushed upstream by myself, some others by other developers (for instance I will apply patches found on sourceforge to support our non-UHCI/OHCI USB host controller, and I don't want to push code for which I'm not the maintainer upstream), and some device drivers will not be pushed at all.

I will base my work on the Linux kernel 2.6.15, which is the most recent release that has the features I need (2.6.16-rc1 broke serial port support on Freescale PowerQuickII processors). I plan to stay up-to-date with the main kernel repository by either fixing the problems in future releases or waiting for someone to fix them, depending on how much time I can spend on the project.

I have no idea how to layout my git repository to work on day-to-day development. I need to :

- commit bug fixes, external patches and internal modifications to a branch 
(or possibly on separate branches depending on what I commit if needed). The 
work will be based on Linux kernel 2.6.15 but I'd like to stay up-to-date 
with the master repository as much as possible.
- push bug fixes upstream by creating a patchset and submitting it by email.
- pull changes from upstream and merge them in my various branches when the 
upstream versions become stable enough.
- keep branches for all the versions shipped to the customers for bug fixes.

I'm the only developer working on the Linux kernel in my company, but that might change in a few months, so other developers will need to use git as well.

Is git able to accomodate my needs ? I've been trying to setup a git repository with a few branches over the last two days, but I always had to throw everything away and start back from zero. I haven't been able to figure out which branches I should create and how I should use them.

Thanks in advance for your help, and I hope I'm not asking too much. If really unable to use git, I'll go for SVN (or SourceSafe as that's what my company used until today, but I'd like to avoid it) even if I feel it will make keeping up-to-date with upstream more difficult.

Laurent Pinchart

On Wed, Feb 01, 2006 at 12:38:44PM +0100, Laurent Pinchart wrote:

Those certainly sound like the kinds of things it's meant for.

Maybe you could be more specific about the problems you've had?

--b.

Laurent Pinchart <laurent.pinchart@tbox.biz> writes:

Bruce already responded to this part in a more polite way, but let me be more blunt. You need to figure out how your project and workflow is to be organized first, and that needs your own thinking. We could help, but you know your project better than any of us. The organization of what git branches to use and how would fall out as a natural consequence of your workflow.

And I suspect you would have the same workflow issues regardless of the choice of any SCM (some SCM may _force_ particular workflow on you though; which may be a good thing -- it reduces confusion coming from having too many possibilities to choose from).

For example, with my simplified world view, I would do something like this:

master::
	the tip of the latest of your product.

vanilla::
	the tip of the Linus vanilla kernel. you do not
        commit to it---you only update it via "git fetch".

kfix::
	forked somewhere from refs/heads/vanilla, and may
        occasionally be updated by merging from it, to
        hold your own bugfixes meant for mainline.

maint/1.0, maint/1.1, maint/1.2,...::
	forked somewhere from master when you do a release.

Your product specific work is done in master. In practice, you probably would emply "topic branch" workflow to grow the master, but that is covered pretty well by Tony Luck in one of our howto documents, so I would not repeat it here. External patches you pick up from elsewhere would go in the master as well.

When working on bugs present in the vanilla kernel, You checkout kfix, work in there and commit fixes to this branch. It may be a good idea to occasionally sync this branch with vanilla when your changes conflict with upstream changes. This is the branch you would publish to the outside world for consumption by the kernel community (other branches probably need to be published to satisfy your GPL obligations as well).

You would merge from kfix into master as needed.

When you release your version 1.0 product, you would tag "master", and at the same time, branch "maint/1.0" from there. Further post-release fixes you would commit to maint/1.0 branch. You might make further tags 1.0.1, 1.0.2 on this branch as needed.