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

[Avery Pennarun <apenwarr@gmail.com>]

On Fri, Jun 5, 2009 at 12:30 PM, Kelly F. Hickel <kfh@mqsoftware.com> wrote:
>        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