[email protected] said: > On 3 March 2015 at 10:03, Martin Lucina <[email protected]> wrote: > > [email protected] said: > >> Isn't that mainly a different version of submodules where the subtrees > >> are going to continue to exist and you may want to pull changes? Don't > >> we just want to do a straight merge to keep the histories and then > >> phase out the old repos? > > > > AFAICT this (git subtree) does exactly what you're describing -- the > > problem with doing it any other way is that we have overlapping filenames > > in the repositories and you'd have to rewrite their histories to be able to > > just pull the changes from both into the unified repository. > > > > Unlike submodules, the resulting commits live fully in the new repository, > > so after the merge we'd just clean up the duplicate bits manually and > > deprecate the old repositories as planned. > > Oh I see. I think you can also > take empty repo > create new branch > merge repo1 > git mv to subdir > repeat for repo 2 > merge both branches into master > > Looks like both have the same effect though.
I hadn't thought of doing it that way (git mv on a branch). Just tried it and it seems to even better than the subtree approach, which has problems with "git log --follow PATH" and "git blame" not working quite right in the resulting repository. I'll write a script to do it your way and send it to the list shortly. Thanks :) -mato
