Carrying security branches in the main git repository

[Tim Gardner]

Andy (aka git wizard),

I've been struggling with rebasing the security branch back into master
and am finding that it doesn't really work all that well. Of course, the
code patches rebase just fine, but where I'm having some real conflicts
is with some of the generated administrative files such as those in
debian/abi (and to some extent debian/changelog).

What I'm considering is to just name the security branch with its
release version (such as security-2.6.27-9.18), cherry-pick the security
branch code commits back into master, and push the whole mess up to
zinc. The one thing I want is the ability to reliably reproduce the
security kernel. This method seems to satisfy that criteria, as well has
making sure master contains all of the security kernel code patches.

Another advantage is that with this method I don't have to arbitrarily
fix the changelog. The content of changelog for the kernel in a
particular pocket accurately reflects the changes that went into that
kernel. Whereas, in the past I was hacking security changelog sections
into an arbitrary location in the master changelog, the results of which
Stefan and I have not always agreed.

Thoughts?

rtg
-- 
Tim Gardner tim.gardner at canonical.com