list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <>
To: Piotr Krukowiecki <>
Subject: Re: Merging (joining/stiching/rewriting) history of "unrelated" git repositories
Date: Wed, 15 May 2019 17:25:31 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 script
> (
> but it's slow, memory inefficient and handles "master" branch only...
> Thanks,

You might be able to use

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

  reply	other threads:[~2019-05-15 15:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-15 14:52 Piotr Krukowiecki
2019-05-15 15:25 ` Ævar Arnfjörð Bjarmason [this message]
2019-05-15 20:33   ` Elijah Newren
2019-05-16  6:38     ` Piotr Krukowiecki
2019-05-17 13:08       ` Piotr Krukowiecki
2019-05-20 13:54     ` Jakub Narebski
2019-05-21  7:53       ` Piotr Krukowiecki
2019-05-16  6:10   ` Piotr Krukowiecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).