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) _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
