Re: Merging (joining/stiching/rewriting) history of "unrelated" git repositories
- Date: Wed, 15 May 2019 17:25:31 +0200
- From: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
- Subject: Re: Merging (joining/stiching/rewriting) history of "unrelated" git repositories
On Wed, May 15 2019, Piotr Krukowiecki wrote:
> 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
> but it's slow, memory inefficient and handles "master" branch only...
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 :)