Thread (12 messages) flat view 12 messages, 6 authors, 2016-06-15

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

From: Avery Pennarun <hidden>
Date: 2016-06-15 22:46:54

On Fri, Jun 5, 2009 at 12:30 PM, Kelly F. Hickel [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help