Need help: Generating patch using git

Greg KH greg at kroah.com
Wed Feb 1 17:05:54 EST 2012


On Thu, Feb 02, 2012 at 02:47:49AM +0530, Srivatsa Bhat wrote:
> Hi,
> 
> On Wed, Feb 1, 2012 at 10:51 AM, amit mehta <gmate.amit at gmail.com> wrote:
> 
> 
>     > Also the kernel tree you are using seems to be Linus's mainline, is
>     > that what you wanted or did you want to be making the patch against a
>     > linux-next kernel?
> 
>     My current goal is to send some patches to kernel janitor group though I'm
>     not
>     sure if this group is still active or not.
>     you mean to say that this is not the tree which i should be synced to? If
>     not
>     then can you please send me the link to the relevant git repository ?
> 
> 
> 
> Please note that linux-next is just a tree used for integration-testing. I
> strongly suggest
> that you don't base your patches on linux-next. Basing it on current mainline
> is generally a good idea. But if you are doing some significant development,
> you should target the individual trees that the subsystem maintainers maintain.
> 
> To put it in simple terms, base your patch on current mainline and send it to
> the appropriate people (use get_maintainer.pl in the scripts directory to find
> whom to send it to). Then if the maintainer specifically asks you to rebase
> your
> patch on some particular tree that he maintains, then do it. Then you know what
> to do with patches related to that subsystem from next time onwards :-)

As a subsystem maintainer, I strongly disagree with this.

Do your work against linux-next, as that contains the different
subsystems already.  You don't want to do something only to find out you
need to totally redo it, or just throw it away as someone else has
already done it (which is quite common for janitorial and other "simple"
tasks).

So please, either work against linux-next, or the subsystem-specific
tree, linux-next is usually easier, the odds of cross-subsystem merges
causing problems with your change, for the subsystem maintainer, are
very low, much lower than the fact that major changes might have already
happened.

greg k-h



More information about the Kernelnewbies mailing list