<> ||<>|| Git is the source code management tool used by the Linux kernel developer community. Ubuntu has adopted this tool for our own Linux kernel source code so that we can interact better with the community and the other kernel developers. <> <> == Maintaining local changes == During development, the kernel git repository is being constantly rebased against Linus' tree. In other words, Ubuntu specific changes are not being ''merged'', but rather popped off, the tree updated to mainline, and then the Ubuntu specific changes reapplied. There are two ways to track the kernel git tree, depending on whether you have local changes or not: '''No Local Changes''' {{{ git fetch git reset --hard origin/master }}} '''Preserve Local Changes''' {{{ git fetch git rebase --onto origin/master origin/master@{1} }}} == Pushing changes to the main repo == Since the main repo is not publicly writable, the primary means for sending patches to the kernel team is using ''git format-patch''. The output from this command can then be sent to the [[mailto:kernel-team@lists.ubuntu.com|kernel-team]] mailing list. Alternatively, if you have a publicly available git repository for which changes can be pulled from, you can use ''git request-pull'' to generate an email message to send to the [[mailto:kernel-team@lists.ubuntu.com|kernel-team]] mailing list. <> == Patch acceptance criteria == In general, Ubuntu will apply the same criteria applicable to upstream kernel. Here is a checklist of reading and tools related to posting kernel patches: * /Documentation/SubmittingPatches * /scripts/checkpatch.pl * /scripts/cleanpatch * /scripts/cleanfile * /scripts/Lindent If you are creating a new file, it is helpful to run it through ''cleanfile'' and/or ''Lindent'' before creating a patch<
> If you have generated a patch, it helps running it through ''checkpatch.pl'' and ''cleanpatch'' if necessary<
> Also, using the commit template described above is a good idea for Ubuntu-specific patches == [old] Developers with access to kernel.ubuntu.com == The kernel team has a ''git'' repo located on ''kernel.ubuntu.com'' (AKA zinc.ubuntu.com) in /srv/kernel.ubuntu.com/git/ubuntu. You can, if you want, create a clone for yourself in your directory, and just have your changes pulled when ready. Suggested way to do this: {{{ git clone -l -n -s --bare /srv/kernel.ubuntu.com/git/ubuntu/ubuntu-jaunty.git vi ubuntu-jaunty.git/description ( give it a descriptive name ) mv ubuntu-jaunty.git/ /srv/kernel.ubuntu.com/git//my-git-tree.git }}} You can now push your changes to this tree via '''ssh'''. Note the '''-l -n -s''' options do a few special things, mainly making your repo share objects with ours (saves space). Now you need to run ''git update-server-info'' in your tree so that it is available over http transport {{{ cd /srv/kernel.ubuntu.com/git//my-git-tree.git git update-server-info mv hooks/post-update.sample hooks/post-update chmod +x hooks/post-update }}} For older versions of git instead of using the post-update hook use {{{ chmod +x /srv/kernel.ubuntu.com/git//my-git-tree.git/hooks/post-commit }}} To work on your branch, now clone to your local machine from the same origin tree (not the tree you just created on zinc -- this is only for pushing to): {{{ git clone git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git my-tree git remote add zinc ssh://kernel.ubuntu.com/srv/kernel.ubuntu.com/git//my-git-tree.git git push zinc master }}} Suggested method for keeping this tree synced with the ubuntu tree, instead of git pull, is to do: {{{ cd my-tree git fetch origin git rebase origin }}} This will keep your changes on top of the original tree (as opposed to being merged). This is also a good idea because during development (e.g. while following the upstream git repo), we frequently rebase to linux-2.6.git upstream, so the '''HEAD''' is not always suitable for pull/merge.