Show 48 quoted lines
> -----Original Message-----
> From: Avery Pennarun [mailto:apenwarr@gmail.com]
> Sent: Friday, June 05, 2009 12:01 PM
> To: Kelly F. Hickel
> Cc: git@vger.kernel.org
> Subject: Re: Best way to merge two repos with same content, different
> history
>
> 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