On Wed, May 15 2019, Piotr Krukowiecki wrote: > Hello, > > I'm migrating two repositories from svn. I already did svn->git > migration (git-svn clone) and now have two git repositories. > > I would like to merge them into 1 git repository, but to merge also > history - branches and tags. > > The reason is that the svn repositories in fact represent one > "project" - you had to download both of then, they are not useful > separately. Tags were applied to both repositories, also list of > branches is almost identical for both. > > So right now I have: > > - projectA: > master: r1, r4, r5, r7 > branch1: r10, r11, r13 > - projectB: > master: r2, r3, r6 > branch1: r12, r14 > > The content of projectA and projectB is different (let's say projectA > is in subfolder A and projectB is in subfolder B). So revisions on > projectA branches have only A folder, and revisions on projectB > branches have only B folder. > > But I would like to have: > > - projectAB: > master: r1', r2', r3', r4', r5', r6', r7' > branch1: r10', r11', r12', r13', r14' > > Where all revisions have content from both projects. For example, the > r5' should have the "A" folder content the same as r5, but also should > have "B" folder content the same as in r3 (because r3 was the last > commit to projectB (date-wise) before commit r5 to projectA). > > There's additional difficulty of handling merges... > >> > Any suggestions on what's the best way to do it? > > > Currently I'm testing join-git-repos.py script > (https://github.com/mbitsnbites/git-tools/blob/master/join-git-repos.py) > but it's slow, memory inefficient and handles "master" branch only... > > > Thanks, You might be able to use https://github.com/newren/git-filter-repo But I'd say try something even more stupid first: 1. Migrate repo A to Git 2. Migrate repo B to Git 3. "git subtree add" B's history to A 4. "git rebase" the history to linear-ize it At this point you'll have A's history first, then B. Then run some script to date order the commits, and just "git cherry-pick" those in the order desired in a loop to a fresh history. Maybe that sort of stupidity will wreck your merges etc., so you might need less stupid methods :)
