| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 30 Oct 2008 21:34:17 -0400 From: "J.R. Mauro" <jrm8005@...il.com> To: "Greg KH" <greg@...ah.com> Cc: "Linus Torvalds" <torvalds@...ux-foundation.org>, linux-kernel@...r.kernel.org Subject: Re: merging other repos into linux-2.6 On Thu, Oct 30, 2008 at 1:49 AM, Greg KH <greg@...ah.com> wrote: > Hi, > > In working with some of the current out-of-tree drivers, some of them > are asking if they could keep their past development history when > merging the code into the main kernel tree. > > Now normally we don't do this for new drivers, just dropping them in in > one big patch, or sometimes multiple patches to get it through email > filters. > > The comedi group (data acquisition subsystem for Linux) have their whole > history going back to 2000 in a git tree (well, a cvs->git repo.) That seems to go back further than Linus's kernel tree goes. Would this be a problem? > > I was wondering if it would be acceptable to graft their tree into the > linux-2.6 tree (after moving the files to the proper location) to keep > their whole old history alive. > > Now what good that old history would do, I really don't know and can't > think of a solid reason to need it, other than to give proper authorship > credit for the various individual drivers and parts of the code (which > is good to have at tims.) > > But the merge looks pretty cool, and it is impressive that git can allow > this to happen, so there are some extra "style" points a merge like this > would give :) > > So, any thoughts? Should I graft the trees, or just stick to simple > "here's the whole driver" type patches like we have been doing? The Comedi project looks really big, so I can understand wanting to get the history for it simply because it's a ton of code. But if this is as hard to do properly as Linus says, I would be wary of the precedent merging in their history might set. Suddenly we could have tons of developers clamoring for the same treatment. If files are being moved and the directory layout of the foreign repository is nothing like the kernel's layout, could all the old revisions be formated in one huge patch series against a single subdirectory? Sure the dates relative to the old work would be totally wrong, but we would not have to worry about breaking bisections, et al, while still retaining the content's change history. That course would depend on how Comedi's repo is laid out and how the layout will be done to put them in the kernel tree, as well as how important the difference between 'content creation time' and 'commit time' are to those involved. If it's just a matter of having accountability and the ability to look at old versions, perhaps that difference is not very important. Any way you do this besides the One Big Patch approach would seem to screw up the history for someone. I think it would be safer to tinker with the outside project's view of the past than the kernel's. > > thanks, > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists