branching and supporting a tagged kernel version

Hello,

I was trying to see if I can use git for a particular way of supporting a kernel and was hoping for some feedback if this approach would work.

Basically I wanted to branch off of 2.6.14 and support personal patches. However over time I would like to be able to merge in hand-pick commits from upstream.

So my questions (for now) are:

1) what is the easiest way to branch off on a tagged version (in this
case 2.6.14)?  I didn't quite understand what <starting point>
referred to in the git-branch docs.

2) is there a way to get a list of commits from upstream that are not
in my branch and then selectively apply them?  Yes, I understand the
potential merge mess...

Thanks, Don

Don Zickus <dzickus@gmail.com> writes:

Starting point is badly worded, but essentially it means "anything that names a particular commit". That's the commit you want to base your branch off of.

In your case, you would run:

------------ $ git clone git://git.kernel.org/pub/.../torvalds/linux-2.6/ my2.6 $ cd my2.6 $ git checkout -b private v2.6.14 ------------

to create and checkout a branch called "private" to house your personal changes, based on v2.6.14. Your working tree is based on v2.6.14 and you are on the "private" branch immediately after this operation, and you should see no diff from either of these commands:

------------ $ git diff v2.6.14 <1> $ git diff private v2.6.14 <2>

<1> compare your work tree with v2.6.14 tagged by Linus <2> compare "private" branch head with v2.6.14 tagged by Linus ------------

Then work as usual, the cycle is:

------------ $ edit $ git diff ;# to see how well you are doing $ compile $ test $ git diff HEAD ;# final review before committing $ git commit -a ;# commit all changes as you tested ------------

I'll refrain from saying that it is not the usual way to work with git, since you seem to know what you are doing. So let's assume that you somehow do not ever want to merge from Linus head into the "private" branch.

After you have worked there:

------------ $ git fetch origin $ git cherry origin private ------------

would show the list of commits since you forked from origin, which is Linus head --- when you run "git clone" to set up "my2.6" repository, it would have made .git/remotes/origin shorthand that has this line in it:

------------
URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Pull: master:origin
------------

pick the ones you want, and apply them with:

------------ $ git cherry-pick 12233445.... ------------

Thanks for clearing things up.

Either this or cvs. :) Anyway my work involves releasing a platform to customers who don't want to constantly upgrade their kernel. And instead of waiting for bugs to be filed, I was just trying to find a way to be pro-active and fix certain bugs _before_ our customers hit them.

Cheers, Don

Dear diary, on Tue, Dec 13, 2005 at 12:58:38AM CET, I got a letter where Don Zickus <dzickus@gmail.com> said that...

You might also consider managing your patches in StGIT, which could give you more comfort for managing them. StGIT provides quilt-like functionality on top of GIT, and it's easy to reorder, add, and remove patches, as well as submit them to the upstream and remove them automatically when they get merged.