0

There are 3 projects each with their own git repo:

  • Project A, a project independent of B
  • Project B, a project independent of A
  • Project AB, a project that uses some of A and some of B. An amalgamation of sources, file structures, etc, with some modifications to allow the two to blend properly.

Project A and Project B are mostly dead, but did receive minor patches after AB was created, some of which were later ported to AB. AB's git repo was created without history from either A or B. It is easy for me to tell which file or directory came from A and which came from B, and I know what commit each of the initial files was taken from.

How do I Restore history for AB before the init, assuming that all files in AB are based on files from A or B?

Keep in mind the following:

  • Files from A may be in a B-like directory, and vice versa, so I should be able to handle moves
  • At some point, I'd like to rebase AB's ported patches so that they are attributed to a merge from either A or B.
  • I would like for A or B to be able to merge AB, although having only one of them be able to do this would be okay, as long as I can control which one.
  • There are about 30-50 files, so it would still be possible for me to rebase for each file, it would be preferred if I didn't have to.
DavidJFelix
  • 728
  • 1
  • 6
  • 22

2 Answers2

2

In general you’d probably want to set A and B as parents of your root commit. You can see here how to do that:

https://stackoverflow.com/a/4164767/758345

Git will now understand where these files are coming from and also handle renames etc. You should now be able to merge from A and B into AB.

You can never merge AB into A or B, as AB also contains the other project. You might be able to use cherry-picking, but I doubt that too. If you want changes from AB to be contributed to A and B, you should have a look at submodules and git-subtree.

Community
  • 1
  • 1
Chronial
  • 66,706
  • 14
  • 93
  • 99
  • What I really meant by merging AB into A or B was to introduce A files to B or B files to A by making AB accessible to A maintainers or B maintainers. The goal is really to move on with AB, but to reach out to people "stuck" in A or B. – DavidJFelix Feb 20 '13 at 13:57
  • As I said, merging AB into A or B is *very* problematic, unless A and B are in separate directories within AB. Alternatively, you could write a helper script that sorts out the parts of AB that belong to A or B. But to my knowledge, git does not contain any functionality of this sort. – Chronial Feb 20 '13 at 16:04
0

To create commits before your root-commit would require a rebase of the entire AB repo.

Perhaps a different way to bring in those old commits would be orphan branches

git checkout --orphan project-a
git rm -rf .
git remote add upstream-a git://foo.org/project-a
git pull upstream-a master

git checkout --orphan project-b
git rm -rf .
git remote add upstream-b git://foo.org/project-b
git pull upstream-b master
Community
  • 1
  • 1
Zombo
  • 1
  • 62
  • 391
  • 407
  • I think I'd like to rebase because it maintains a directed history of the files. My goal is to have the repo AB in a state where patches can be sent to A or B or both A and B so that collaboration can occur between AB and the projects it forked from. – DavidJFelix Feb 11 '13 at 20:13