branching and supporting a tagged kernel version

branching and supporting a tagged kernel version

[Don Zickus]

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

Re: branching and supporting a tagged kernel version

[Junio C Hamano]

Don Zickus <dzickus@gmail.com> writes:

> 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.

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

> 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...

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....
------------

Re: branching and supporting a tagged kernel version

[Don Zickus]

Thanks for clearing things up.

> 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

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

Re: branching and supporting a tagged kernel version

[Petr Baudis]

Dear diary, on Tue, Dec 13, 2005 at 12:58:38AM CET, I got a letter
where Don Zickus <dzickus@gmail.com> said that...
> Thanks for clearing things up.
> 
> > 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
> 
> 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.

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.