[openib-general] [PATCH] for OFED 1.2

Michael S. Tsirkin mst at mellanox.co.il
Tue Feb 27 12:23:31 PST 2007


> Quoting Sasha Khapyorsky <sashak at voltaire.com>:
> Subject: Re: [PATCH] for OFED 1.2
> 
> On 19:44 Tue 27 Feb     , Michael S. Tsirkin wrote:
> > > Quoting Sean Hefty <sean.hefty at intel.com>:
> > > Subject: Re: [PATCH] for OFED 1.2
> > > 
> > > >I think with stacked git or just git and rebasing at key times, you
> > > >could keep an ofed_1_2 tree that folks can easily apply patches to...
> > > >
> > > >Its too late to change this for 1.2, but you might want to reconsider
> > > >the design for 1.3.
> > > 
> > > Can't we just create a new branch (ofed_1_2_patched) with these patches already
> > > applied and in the correct order?  
> > 
> > Then what we do when we want to update to new upstream? Throw this branch away?
> > As it is, I just pull then build and remove patches that conflict.
> 
> You can save this branch as <branch-name>-<upstream-name> (or better)
> and to rebase <branch-name> to the new upstream.

rebase does not seem to be too robust when run on such a large repository as the
linux kernel.  Maybe stacked git will work.

> > By the way, there are backport patches, etc - it is still incorrect
> > to say that you would be able to generate a patch out of git
> > and know it's a good one without test-build.
> 
> In similar way you can track backport patch sets as branches.

At the moment it seems like a lot of work. Again, maybe stg makes it easy,
I know it's hard with plain git.

And I think lots of people (including me) will be confused if we have a ton of branches.

> > > Maybe I'm just not understanding the work flow here...
> > 
> > Sean, please install quilt and try using it for working with the system.
> > Adding new patch is usually done in this way
> > quilt new <patch>
> > quilt add <files>
> > edit
> > quilt refresh
> > 
> > cp patches/<patch> kernel_patches/fixes/
> > git add kernel_patches/fixes/<patch>
> > git commit kernel_patches/fixes/<patch>
> 
> This looks strange for me to track patches against patches...

One gets used to it :)
Seriously, we have these patches, and we want to version them together
with source they are intended to apply to.

-- 
MST




More information about the general mailing list