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: Fri, 31 Oct 2008 08:57:45 -0400 From: "J.R. Mauro" <jrm8005@...il.com> To: "Kyle Moffett" <kyle@...fetthome.net> Cc: "Linus Torvalds" <torvalds@...ux-foundation.org>, "Greg KH" <greg@...ah.com>, linux-kernel@...r.kernel.org Subject: Re: merging other repos into linux-2.6 On Fri, Oct 31, 2008 at 12:08 AM, Kyle Moffett <kyle@...fetthome.net> wrote: > On Thu, Oct 30, 2008 at 10:38 PM, J.R. Mauro <jrm8005@...il.com> wrote: >> I agree. The only viable automated approach would be something akin to >> git-submodule but with the ability to integrate the submodule'd >> project upon import in such a way that things like bisection would >> follow the main project's ancestry and ignore the submodule's. But >> that's not possible right now and probably won't be in the foreseeable >> future. > > Here's one relatively easy solution: > > (1) Fetch the to-be-merged branch of the "child" project into a > repository with the parent project ($KIDBRANCH) > > (2) Find a branch on which you are going to rebase the child > project's history ($BASEBRANCH) > > (3) Determine a directory into which you are going to put the child > project's history ($SUBDIR) > > (4) Identify the first revision of the child project by looking at > the last (first-in-time) entry in "git log" of that branch. > ($KIDSTART) > > (5) Graft the kid's history onto the parent's history at that point: > echo "$KIDSTART $(git rev-parse --verify $BASEBRANCH)" >.git/info/grafts > > (6) Rewrite the kid's history as a subdir of that version of the parent: > git filter-branch --index-filter 'git read-tree master && git > read-tree --prefix=drivers/newkiddriver/ "$GIT_COMMIT"' -- > "$BASEBRANCH..$KIDBRANCH" > > Now the history of $KIDBRANCH will appear to be a series of commits > which add files in $SUBDIR of the parent project, without any changes > at all to the parent project's tree. You can then do a merge of what > appears to be a normal development branch into the main repository. > > Since none of the files are even remotely referenced, there can be no > possible build failures (hence bisection is not broken). You may then > add commits which add Kconfig options and Makefile references and > happily develop away. > > Cheers, > Kyle Moffett > So this would keep their history but make it look like their first commit (years ago) happened today? Or do I misunderstand you? If it is, this is basically what I was trying to propose, except I didn't have nearly enough git-fu to put it like that. But then if Greg thinks the history is rubbish, I doubt it will get imported, although I think these methods are worth experimenting with for the future. ~J.R. -- 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