Re: merging other repos into linux-2.6

["Kyle Moffett" <kyle@moffetthome.net>]

On Thu, Oct 30, 2008 at 10:38 PM, J.R. Mauro <jrm8005@gmail.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