Carrying security branches in the main git repository

[Andy Whitcroft]

On Thu, Nov 20, 2008 at 07:51:38AM -0700, Tim Gardner wrote:
> 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.

I was envisaging you would merge the security branch into master, as in
a real git merge.  The changes since the 'split' are only the security
patches anyhow.  There is a version tag on the tip which represented the
security version, so you can always re-check that out and recreate the
kernel right?

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

When I simulated the above I could simply ignore the changelog
modifications from the security branch, as subsequent to the merge the
'full list' produced by debian/rules printchanges included the security
commits also.

-apw