0

I have a master git repository, and another repository, that contains code that once was just copied from the other codebase without history, but then versioned by git again.

So the second repository has a much younger history, beginning at some state that is present as one commit in the master repository.

What would be the best way to merge this mess again? I think I first need to find out at what commit the copy was made, how to do that? How to merge the repository as a new branch, but with full history then?

2
  • Related Stack Overflow question.
    – heavyd
    Oct 15, 2014 at 13:38
  • Related, yes. But it lacks the continous history I need, as there the two projects that get to be merged are unrelated, while in my case, the second one is a ancestor of some commit in the master repo.
    – dronus
    Oct 15, 2014 at 16:21

1 Answer 1

0

First off export patches of the old repo.

Apply patches one by one, sequentially on the new repo. Some of the first should give you conflicts. These should be the ones that are already in the repository. Once you get the one that is not failing, you can start from there to create the changed history in the new repo.

The following are the problems with this method:

  • need to commit one by one.
  • author and commit message is lost.

There's another method, which is to brute force the commit hash (see gitbrute) of the first non-conflicting commit. And then create a bundle of the repo from that commit until the last commit in the old repo. Apply this bundle on the new repo.

brute forcing the commit hash is no easy feat, seeing the provided project, which set the prefix of a commit, would get you started.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .