Need help: Generating patch using git

[Julie Sullivan]

Hi Amit,

> I've access to this machine as root also but as you've suggested I can use my
> user login account as well.

Well, it's up to you...it's just that being root all the time makes me
nervous :-)

> 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 ?
>
> -Amit

Kernel-janitors is still very much active, it's a good list to follow
as it is quite low volume (typically between maybe 5 - 10 emails a
day? although it varies) and it's a great way of getting a feel for
how things are done and getting ideas for patches.

What tree you want to be testing against I think really depends on the
patch you are doing, linux-next is supposed to be the official 'tree'
but I think some maintainers have their own they sometimes prefer
developers to use. It's trivial with git to follow these if you need
to though.

I'd recommend following (and looking into doing) some work on drivers
in staging too, if you are trying to find a starting point (the
mailing list for this is devel.linuxdriverproject.org). I _think_ Greg
KH asks people to use linux-next (although staging has its own tree,
to be sure, email before sending the patches).

You can remote track linux-next from your existing repo. (this is how
I do it.) cd into your linux-2.6/ and do this;

$ git remote add linux-next
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
$ git fetch linux-next
$ git fetch --tags linux-next

You will then be all set up to track linux-next.

Then, in the future, do 'git remote update' to update the linux-next
branch so you get all the latest tags each time (this will also update
any other remote branches you have set up to track).

Note that as I understand it linux-next isn't an 'evolving' tree like
mainline, it's best to see it as being a list of individual kernels
released as tags, i.e. you shouldn't be merging one into another.

Stephen Rothwell's notification on the linux-kernel mailing list about
the latest release explains this and is probably worth a read:
https://lkml.org/lkml/2012/2/1/20


To list the tags, do:

$ git tag -l next-*

and the bottom one will be the latest linux-next version.

So in my repo, having just done a remote update, the last few tags
look like this:

$ git tag -l next-*

<...>

next-20111215
next-20111216
next-20111221
next-20111228
next-20120113
next-20120118
next-20120201

The bottom one is the latest release so I can check out this tag, like
so, (with accompanying message below:)



$ git checkout next-20120201
Checking out files: 100% (2741/2741), done.
Note: checking out 'next-20120201'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

 git checkout -b new_branch_name

HEAD is now at bc7f599... Add linux-next specific files for 20120201



Then I can create a new branch from here, e.g.

$ git checkout -b 1st-feb-2012-next

Now I have my own branch to build a linux-next kernel, or work on, etc.



HTH.
Cheers
Julie