How to use git for Linux kernel development ?

How to use git for Linux kernel development ?

[Laurent Pinchart]

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

Re: How to use git for Linux kernel development ?

[J. Bruce Fields]

On Wed, Feb 01, 2006 at 12:38:44PM +0100, Laurent Pinchart wrote:
> 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 ?

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

> 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.

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

--b.

Re: How to use git for Linux kernel development ?

[Junio C Hamano]

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

> ... I haven't been able to figure 
> out which branches I should create and how I should use them.

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.

> ... 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.

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.