> > 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. > I have followed the steps as mentioned above and I have created a new branch which has some trivial changes. After this I ran "checkpatch.pl" script against my patch, which reported no warning or error messages. I sent this patch to myself and was able to apply this patch successfully(In past It didn't worked as I was using gmail GUI client which does not work for sending patches, refer Documentation/email-clients.txt). As this patch does nothing more than just adding some missing loglevels for printks', hence I was wondering if I need to go through the entire kernel build process and boot from the modified kernel and do some tests before sending this patch to kernel-janitor mailing list and the relevant maintainers. To be specific, my changes are under linux-next/net/ipv4 I've read SubmittingPatches but still I wish to know the general steps that one should follow for "janitorial" related changes. -Amit P.S. What i think is trivial can very much be substantial as well as I may not perceive the effects as of now. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
