On Sun, 9 Dec 2007, Wink Saville wrote:

quoted text
> Daniel,
> 
> Worked like a charm, someday maybe I'll understand why it works:)

I should probably explain (now that I know it's actually relevant).

quoted text
> > # Add a project "foo"
> > $ git fetch ../foo refs/heads/master:refs/heads/foo

Get the history and data, as an extra branch, so we can deal with it 
easily.

quoted text
> > $ git merge --no-commit foo

We want to generate a merge commit, but we want to mess with it, so we use 
merge to set it up, but --no-commit to not actually commit it. (The commit 
below will generate a merge commit if we don't cancel stuff entirely.)

quoted text
> > $ git read-tree --reset -u HEAD

Replace the index (--reset), updating the working directory (-u), with 
HEAD (the commit on the local side before the merge we're in the middle 
of).

quoted text
> > $ git read-tree -u --prefix=foo/ foo

Read into the index, updating the working directory, "foo" (the branch we 
fetched above), but with the prefix "foo/" so everything is stuffed into a 
subdirectory.

quoted text
> > $ git commit

And commit the result, which has the tree as constructed above (everything 
from the local parent, and everything from the branch in a subdirectory), 
and has the parents as for the merge we started: first parent is the local 
line without the additional branch, and the second parent is the added 
repository.

And git doesn't care about global structure, so the fact that this commit 
is obviously just what you'd ideally like, while the history as a whole is 
a bit odd (like, it doesn't have a unique start, and development didn't 
start in subdirectories, and...) doesn't matter.

	-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html