On Sun, 9 Dec 2007, Wink Saville wrote: > 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). > > # 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. > > $ 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.) > > $ 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). > > $ 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. > > $ 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
