Boyd Stephen Smith Jr. venit, vidit, dixit 02.12.2008 18:19: ... > It does feel a bit "hacky", I was hoping git would have better support > this, through the subtree merge or something else. It seems like > something that might happen to others, perhaps as a side-effect of a > failed attempt at using submodules. Well, except for 'tar' my solution uses only git commands ;) > I can't help thinking that rebase -ip might have helped. I wasn't aware > of -p when I was initially working on this problem. (It doesn't help that > I generally use Debian stable, and git 1.4 did not have -p.) rebase rebases one branch at a time, but you need to rebase/rewrite several, and the merge info between depends on rewritten sha1s. ... > I probably don't need the -f. If there are files that should be ignored > (and thus shouldn't be in the repo), I'll filter-branch to cut them out of > the history at some point. '-f' is about not having to clean out refs/original from a previous filter-branch run. > What *exactly* is the subtree merge. The documentation I've read sounds > like this case, sort of, but it's rather unclear to me. I think 'subtree' does what you want, but 'merge' doesn't! 'subtree' saves you the rewriting (putting TI into project/web), but you want a one-time conversion anyway. 'subtree' allows you to repeatedly merge branches with a different root. What it does is it looks for subdir, 'rewrites' the incoming tree automatically and merges the result. But you don't want a merge, do you? Or else your whole TI history would be tacked onto FT's head "to the left": a new (subtree) merge commit would have FT's and TI's head as parents. This is one way of storing TI history in the full repo, but not the one you said you wanted. Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
