> Quoting Sasha Khapyorsky <[EMAIL PROTECTED]>: > Subject: Re: [PATCH] for OFED 1.2 > > On 19:44 Tue 27 Feb , Michael S. Tsirkin wrote: > > > Quoting Sean Hefty <[EMAIL PROTECTED]>: > > > 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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
