Using git to maintain patches [was Re: Heads-up: brand new RPM version about to hit rawhide]

[Mark McLoughlin]

On Tue, 2008-07-15 at 12:24 -0400, Dan Williams wrote:
> On Tue, 2008-07-15 at 08:15 -0800, Jeff Spaleta wrote:
> > On Tue, Jul 15, 2008 at 8:01 AM, Dan Williams <dcbw at redhat.com> wrote:
> > > Yeah, there is actually a benefit to tarball+patches approach we take
> > > right now; and that benefit is that it's extremely easy to see just what
> > > we've done to the upstream package, and it's usually really easy to
> > > extract those changes and push them upstream.  You don't want a
> > > mega-diff that includes 20 specific patches.
> > 
> > I know of at least one example currently in our cvs where we went from
> > a set of separate small patch files to one encompassing patch file.  I
> > think it was a diff from git. If we move to more advanced vcs are we
> > going to have a harder time keeping patches separated? Or is it just a
> > matter of education on how not to reach for the easy to produce mega
> > patch shortcut?
> 
> That's the problem here:  if we move to git (or any DVCS really), as a
> packager you would have to be _much_ more aware of how to use the VCS to
> achieve the same separation of patches and upstream source.

That is true; and there's definitely a steep learning curve there.

I'm not sure the learning curve will always seem incredibly steep - as
we figure out the best way of doing this stuff and more people become
comfortable with it, I'm sure that it would become just as easy a
methodology to pick up as tarball+patches ... which isn't exactly a walk
in the park the first time you do it, either, if you think back.

>   You'd need
> to do something like topic branches for each patch and then merge each
> topic branch into a "release" branch to ensure that each of the patches
> was cleanly separated from the main source.

Not at all - "git-rebase -i" allows you to very easily maintain a set of
git commits as if they were individual patches.

e.g. I use this git tree:

  http://git.et.redhat.com/?p=linux-2.6-fedora-pvops.git

to maintain the set of patches for kernel-xen[1]. The only tricky part
right now is that the that stock Fedora kernel isn't maintained in git,
so I first import all those patches into git as a single commit.

The point is, that if you maintained the kernel patches in git, the
latest kernel was based on v2.6.26-rc8 and v2.6.26-rc9 was released you
would just do:

  $> git-rebase v2.6.26-rc9

and any patches that had gone upstream would automatically be dropped,
you'd have a nice interface for resolving conflicts etc.

If you then wanted to drop, re-order, edit, split up or merge patches
you would just do:

 $> git-rebase -i v2.6.26-rc9

Truly, after doing this for a while, I wouldn't dream of going back to
tarball+patches for maintaining a package with a git upstream/mirror.

Cheers,
Mark.

[1] - touch wood, this kernel is going away soon ... at last and forever