Merge unrelated histories and keep parts unrelated

Wouldn’t rebasing the unique branches off of the local master cause them to be based on the last commit of the local master?

Yes, that is true, but if you need a branch that only contains stuff from one of the original repos you can see how that might be possible given my instructions. Though, personally, such a configuration would be pretty fragile to maintain.

What I’m trying to do, is join 2 git repositories together that have several branches. Some of those have split of from master, but should be maintained as such (since they represent different versions of the software)

I’m afraid that I’m not understanding what your end state goal is. It sounds like you have the following:

  • Two repositories with completely unrelated histories
  • Each repository has a master branch
  • Each repository has several branches off of their own master branch

If all you want to do is smash the two repositories together and continue having completely unrelated histories, you can do that, though I’m not sure what the advantage is there over having two separate repositories.

If you want to merge the two repositories’ master branches and keep the derivative branches without rebasing, you can do that too by simply stopping right before the rebase step in my instructions. Though when you merge those derivative branches back into the new unified master eventually, you’re going to have to do the work of merging in the effects of the commits from the opposing repository. This seems to me like you’re putting off a potentially large merge conflict burden and allowing it to grow larger with time.

If you want to merge the two repositories’ master branches and keep the derivative branches without rebasing and never intend to merge them back into master, you can do that too, though I’m not sure what the advantage is for bringing those branches into the new unified repository then.

Mechanically, there are an infinite number of options. What is most important is why you want to merge these two repositories and how you want to work with them into the future. So if you can share that information, then perhaps I can give better recommendations as to what strategy you might want to choose to solve the problem you have.

OK, let me try to explain this clearly.

We have several repositories (but an example for joining two of them could obviously be used to join all of them). Those repositories each hold a “package” of the same software, and thus will have no conflicts as they are each in a different folder. But they are updated together. This means that when we update the software, we have to commit in many different repos. It also means that what a version of the software is, is defined across multiple repos. This is done by making branches of the same name in those repositories, e.g. each repo would have a v1.1, v1.2,… branch. These branches represent old versions of the software and don’t need to be merged with master again, but sometimes fixes do have to be applied to them.

We want to make one repository that has a master branch and a v1.1, v1.2,… branch that contains all the commits from the different repos.

Ideally, I think, we would have branches containing a linear sequence of commits interleaving the commits from the different repos. But for now, I’m just trying to get a merged branch for each (which I think might be done by, as you suggest, stopping in your example before the rebase step.

Ok, so you’re concerned about rebasing the old branches off of the unified master because that would then bring in changes that aren’t supposed to exist in those versions. I understand now, thank you.