CODEWITHSUNDEEP
gitlinux-kernelpatch
Adil
Adil

Reputation: 2538

Kernel source: Submitting patch

I am trying to work on Linux stock kernel (linus tree). But due to some limitation on my Linux box, I cannot pull the tree through git. So I am downloading the latest rc candidate source archive from kernel.org and then creating my own git repository treating the base source as master. Now I created a branch from it and tries to fix some sources. I have been able to create a patch through git format-patch and wanted to submit it. Again due to no internet connection availability, I have to transfer the patch file to other machine and issue the git send-email command. My questions:
1. Am I doing the right way? I mean the patch generated not directly git clone sources but on my local repository (but yes the base source is same as linus tree)
2. I have seen that in the generated patch the last line has some numbers.

For example

--
1.7.7.3
Not sure what it is all about and does it affect in applying at the base source if my changes are approved by maintainer?

Upvotes: 1

Views: 413

Answers (1)

Roland
Roland

Reputation: 6573

It is fine to send a patch that is generated against something other than the main git tree, as long as the patch applies cleanly against the tree you expect the maintainer to apply it to. The one case where I could see you having problems with your workflow is if you download a final release (say 3.6) and then send a patch during the merge window (the time between when Linux releases 3.6 and when he releases 3.7-rc1). In the merge window, many changes are added to Linus's tree, and if some of them touch the same place you're patching, then you may need to adjust your patch.

In any case, git format-patch is an excellent choice for creating the patch that you send out, since you will avoid many patch formatting problems that beginners hit. Also, using git send-email to send it is a great idea for the same reason -- you avoid having your mail client mess up whitespace, convert it to HTML, or whatever other annoying stuf it might do.

The last two lines like

--
1.7.7.3

just show the git version that generated the patch file. When the patch is applied with git apply, git am, patch -p1 or whatever, those two lines are ignored and dropped, so they have no effect.

With all that said, I would suggest working on updating your development environment so that you can download a full git tree. Having years of history is very useful for understanding code, and updating to the latest state of the tree is much faster and when you just have to download incremental changes. The ketchup tool for downloading and patching sources is also useful, although not quite as good as using git directly in my opinion.

Good luck submitting your patch!

Upvotes: 2

Related Questions