[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