Re: Grafting mis-aligned trees.

[Michael J Gruber <git@drmicha.warpmail.net>]

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