On Fri, Jun 5, 2009 at 12:30 PM, Kelly F. Hickel <kfh@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html