Hi >> These merge conflicts would disappear if you would be kind enough to >> switch to using the "localversion-" method to add EXTRAVERSION params >> rather than patching the Makefile? > assuming that you use the proper base kernel, I don't > see why that chunk would cause any merge failures ... That's basically the point, I kind of don't want to use the correct base kernel... OK, stop there before you panic... The point is not to give you support grief, but that patch management tools such as git don't think in terms of "patches against specific versions", but they tear up the code into a series of change sets which are stacked on top of each other: I'm trying to use git to keep a fixed series of vserver patches and forward port the *kernel* on those patches (kind of the opposite of how you would develop the patchset). So I'm having some success in: - branch mainline kernel on say 2.6.36 - patch vs-2.6.36(.0) - merge kernel changes up to 2.6.36.1 - patch vs-2.6.36.1 onto vanilla and commit that (basically giving the incremental vs patch) - merge kernel changes up to 2.6.36.2 - patch vs-2.6.36.2 , etc, etc The important bit is that this gives the incremental changes at each step to move upwards in time (obviously beware that only certain points are tested working kernels, but that's not the purpose or a limitation). However, this appears to make it quite straightforward to merge several such trees of patchsets together In my case I'm looking at maintaining a grsec or pax + vserver + aufs patchset. It's fairly straightforward to use the procedure above to work out the incremental patchset for each kernel version and maintaining the joint patchset is vastly easier because we can largely maintain only the incremental changes at each stage. So far in my experiments merging through non major kernel re-org work has been quite straightforward and maintaining a hybrid patch is much simpler However, in the case of linux-vserver, once I apply the vs patch, then try and pull all the new kernel commits to get me up to the next kernel version (in prep to apply the next vs patch), I always get a merge failure on the EXTRAVERSION bump commit... So far I don't know how to script an automated fix to a git merge and then restart the merge... It's basically quite a slowdown in the otherwise simple process of maintaining the patch... > we use the EXTRAVERSION to ensure that everybody who > uses the patch on a different kernel release as intended > gets a proper 'warning' at patch time, It would appear that it doesn't quite achieve this? Only checks that you use the correct minor kernel version? Not that the major version is correct? Also, is this useful? Your biggest problem on the list seems to be debian users still on 2.6.9 or something antique, not users trying to apply the patch to some release candidate of the next kernel? Also, not that I am advocating users trying this, but from my very limited observation so far, largely the patch for 2.6.x.1 seems appropriate to apply to 2.6.x.2? > I don't see why that would be hard to automate for you, > after all, I automated the EXTRAVERSION change as well, > with a simple sed line ... I am trying to use a more modern patch management process, in this case git. It has automated processes to maintain a series of patches and there isn't an obvious way to insert an extra step to run some sed recipe part way through a merge? I dont think the situation would change if I used mercurial/bzr/quilt, etc though - fundamentally it's a deliberately inserted merge failure (in your case to stop the theoretical mis-application to the wrong version, in my case stopping me easily generating a series of incremental patches) Additionally every patchset wants to show it's hand in EXTRAVERSION, and localversion- was basically added to make this process scalable (I want to show aufs+grsec as well as vs versions) I would be grateful if you would weigh up a genuine (small) barrier to using the vserver patch more easily/widely vs the possibility of someone learning to use the "-p1" feature of patch and then "accidently" applying the patchset to the wrong base kernel, and come down on the side of ease of use... (pretty please...) I will write a second email with a suggestion on how you might find git useful for your own internal process - so far it seems like it might work pretty well for forward porting vserver patches to new kernels?! (To be clear, I'm doing the reverse, forward porting the kernel onto the old patch...) Kind regards Ed W