Re: Best way to merge two repos with same content, different history

From: Avery Pennarun <apenwarr@gmail.com>
Date: Jun 5, 2009, 17:01 UTC
Message-ID: <32541b130906051001k1ea4d960m4fcf7679b5b4f740@mail.gmail.com>
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794303117DBF@emailmn.mqsoftware.com>

On Fri, Jun 5, 2009 at 12:30 PM, Kelly F. Hickel <kfh@mqsoftware.com> wrote:

Show 12 quoted lines

>        Stated another way, I have two repositories, "new" and "old",
> where the files in the initial commit on branch "B1" in "new" have
> exactly the same content as the last commit on branch "B1" in "old".
> There also exist various branches in "new" based on "B1".  I'd like to
> merge all the commits from "new" into "old", but the SHA1s are
> different, presumably because the history leading up to those points are
> different.
>
>        Other than using manually format-patch on every branch in new,
> then applying the patches (presumably with regular old patch, since the
> ancestor commit IDs won't match), is there any "good" way to merge "new"
> into "old"?

The usual replacement for "manually using format-patch" is to use "git rebase." It does pretty much exactly what you're describing, assuming you don't do too many complicated merges in the meantime.

Another option is to use the .git/info/grafts file. Here's a brief intro: http://git.or.cz/gitwiki/GraftPoint

You'd use that to pretend the parent of your top-skimmed branch is actually the equivalent commit in your new branch. Then could run "git filter-branch" to make the graft permanent, and get all your users to switch to the new repository.

Or you could skip the filter-branch stuff and keep the really hold history somewhere else, available for use if someone installs the graft in their local repo. This would lead to a smaller repository in the general case. (I gather that's what the Linux kernel does for per-2.6.11 versions.)

Have fun,

Avery