Re: Merging (joining/stiching/rewriting) history of "unrelated" git repositories

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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 :)