Not able to preserve history for certain time while merging two repos in GIT

I had a repo structure like this before 1 year :

repo1/ subrepo2/ . . .

before one year I moved the subrepo2 to its separate repo so I created 2 repos :




for one year I made changes to both the repos and now I have to merge them back preserving history.

when I am trying to follow the steps available in most of the questions, I cannot see the history for that one-year , and I do not want to lose it.

Please help.

the steps I followed for merging them back :

in subrepo2 branch:

git filter-branch -- --all
mkdir subrepo2 
mv * subrepo2
git commit -m "moving everything in a directory"

then in repo1 branch

git remote add migration feature/migration <path to>/subrepo2
git pull -f migration --allow-unrelated-histories
git remote -rm migration
git commit

There are some terminology problems here which need to be clarified. To put one repository inside another repository you need to use Git submodules, and you can only include a repository as a subfolder of the host repository. They’ll still be two independent repositories, but the nested repository will be visible to the hosting repository.

So your initial description can’t be right, i.e. before you “moved the subrepo2 to its separate repo” you must have had just a single repository (no matter how you called its subfolders).

When you work with a repository containing another one as a Submodule, changes to each repository are still being committed separately to each other — i.e. when you CD to the submoduled folder, you’re actually entering the other repository.

I’m not sure what you really did here, but I’m assuming that during the initial time you had only one repository, and then you split that into two separate repositories and worked independently on each, and now (after 1 year, if I understood correctly) you’re trying to re-combine them into a single repository, but you would like to do so without loosing their individual history.

If that is the case (i.e. if I’ve understood you correctly), then you only need to put repo2 into a subfolder of repo1 as a Submodule. To do this, you should first read carefully the documentation on Git submodules (or some tutorials, book, etc.), since you’ll need to use some special commands to initialize a submodule, and also define an update strategy, and other details you need to be aware of:

Thanks for replying but I don’t want the two repos to work independently now, by creating a submodule I will have to maintain two repos separately, all I want it to copy the repo2 into repo1 preserving history as I mentioned I did it but was unable to get the history for one year.

After one year there could be a lot of commits involved, which are not going to make manual history re-writing easy. Also, this requires that both repository share some ancestry — I’m still not quite sure from your description if these used to be a single repository once, and how the split occurred (i.e. did you simply fork them apart, as they were, or you deleted their .git/ folders, starting ex-novo?).

If these repositories were publicly available somewhere, for inspection, it would be easier to answer.

before one year I created a new repo and I followed the below steps :
the directory structure was repo1/repo2
so I did filter-branch on repo2 in a branch let’s say migration
and commit the change temporarily

and then created a new repository repo2, and in the branch of that I added in remote migration
then I merged the remote allowing unrelated histories and committed
in this way, I was able to split them up.

sorry, I cant share the repository details.

if during this operation you preserved the original repository history you should still have some shared commits between the two repositories, which could be useful to cleanly rejoin them using these common commits as a way to rebuild a unified tree.

Lacking that, you’ll probably have to do a lot of rebase operations when injecting the second repository into the old one — which means that you’ll be able to preserve the former’s history, but not identical to the original, since rebasing (and all history rewriting operations) will change the commits hashes. Again, it depends on what you expect from your preserved history.

If you’re going to dump for good repository 2, then having the commits change hash shouldn’t be a big deal, and you’ll still have access to the full history in terms of commits, branches, etc. But if preserving the original hashes, signatures, etc. is a requirement, you’ll have to settle for Submoduling repo 2 into repo 1, I’m afraid.

In any case, you’ll probably need to create an orphan branch to inject the branch from repo2 into repo1, and the rebase it on what you want to be the common ancestry point (probably that would be the commit where you split them, i.e. pretending it never happened, which might also require trimming some unneeded commits in repo1, possibly).