[Kde-scm-interest] Re: conversion howto: importing subproject history

[Johannes Sixt]

Am 11/28/2010 0:36, schrieb Oswald Buddenhagen:
> moin,
> 
> just read this question on irc, and i suppose more people run into it:
> a subproject has been developed in a separate subtree and was later
> moved into the project which is being converted now. a straight history
> is obviously not able to represent that. the solution:
> 
> - convert the history of the subproject separately up to the point where
>   it moves into the main project
> - make an interactive rebase of the main project and make it stop at the
>   commit where the subproject moves into it (mark the commit for edit,
>   obviously)
> - note that sha1, then throw the commit away with reset --hard HEAD~1
> - git remote add -f subproject1 /path/to/subproject1
> - git merge -s ours --no-commit subproject1/master
> - git cherry-pick <remembered sha1>
> - git rebase --continue
> 
> this is a variation of a subtree merge - see
> http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
> (you'll need that for later subproject merges anyway, so read it ;).
> 
> the rebasing will take ages for a big project, so mark all subproject
> moves in one go in the rebase editor.

IMO, git-filter-branch will be less painful. Just install a graft that
records the merge point:

echo $(git rev-parse M M^ X) >> .git/info/grafts

where M is the commit in the main history where the sub-project was
integrated, and X is the tip of the history where the sub-project was
stand-alone.

Now:

git filter-branch -- --all

will fuse the histories.
-- 
"Atomic objects are neither active nor radioactive." --
Programming Languages -- C++, Final Committee Draft (Doc.N3092)