Re: Merging (joining/stiching/rewriting) history of "unrelated" git repositories
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- May 15, 2019, 15:25 UTC
- Message-ID
- <874l5vwxhw.fsf@evledraar.gmail.com>
- In-Reply-To
- <CAA01CsoJf+_-iowdm0EFWd52vOWE1Uo0GGZ55d3RyPJzg6gwgQ@mail.gmail.com>
On Wed, May 15 2019, Piotr Krukowiecki wrote:
Show 50 quoted lines
> 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 :)