How do I combine two Git repositories, one a snapshot of the other with current history?

Question

I need to do the inverse of this question.

So almost a year ago we split our Git repository off from itself by copying the current state of both branches into a new repository. To make it simple:

<== 2015 Dec              1 Jan                    2016 Jan ==>
Past history, till SVN    New Repo First Commit    All commits to present

We will soon be using subtrees to turn each of the projects in this repository into its own Git repository, but I do not want to do that so long as we are missing 5 years of our commit history in our central repository. Here are the steps I've tried so far:

cd ProjectFull/
git reset --hard # Project was in a branch
git checkout master # Go to master before trying to rebase
git remote add ProjectSplit ../ProjectSplit # New repository is in another directory
git fetch ProjectSplit # Fetch new repository
git cherry-pick <initial commit hash> --strategy-option theirs
git pull --rebase -s recursive -X theirs origin master

My idea was to cherry-pick the new repo's initial commit and then rebase off of that commit, but that fails. The commands I've listed above do not error out, but they delete all of the history of the old repository.

Here's a truncated log of my Git rebase:

$ git rebase origin dev
First, rewinding head to replay your work on top of it...
Applying: Merge branch 'dev' of <REPO> into dev
Using index info to reconstruct a base tree...
<stdin>:298480: trailing whitespace.

<stdin>:298553: trailing whitespace.

<stdin>:298559: trailing whitespace.

<stdin>:298565: trailing whitespace.

<stdin>:298571: trailing whitespace.

warning: squelched 1751272 whitespace errors
warning: 1751277 lines add whitespace errors.
Falling back to patching base and 3-way merge...

CONFLICT (add/add): Merge conflict in <FILE>
Auto-merging <FILE>
CONFLICT (add/add): Merge conflict in <FILE>
Auto-merging <FILE>
CONFLICT (add/add): Merge conflict in <FILE>
Auto-merging <FILE>
CONFLICT (add/add): Merge conflict in <FILE>
Auto-merging <FILE>
CONFLICT (add/add): Merge conflict in <FILE>
Auto-merging <FILE>
<Same>

Failed to merge in the changes.
Patch failed at 0001 Merge branch 'dev' of <REPO> into dev
The copy of the patch that failed is found in:
   ProjectFull/.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

The script in this answer failed halfway through the old repo's patches.

This answer only works for dissimilar repositories.

Answer 1

Your mileage may vary and I may well have misunderstood the question and your intent, so I'll propose options with short summary:

Consider stitching repos

Perl CPAN has git-stitch-repo, nice module that streamlines git fast-export to git fast-import.

Should linearize history.

Subdir option

Have two dirs instead of one. Or multiple dirs.

You are following procedure for that already. Abandon final cherry-picking from your question and just have old repo as a directory along current one.

Least troublesome, just glues repos together. Doesn't try linearizing history.

Git subtree merge

Merge subtree is a Git command, easier to use than both subtrees and submodules (and less administer-heavy).

You may need to then use --follow when looking at git log for individual files (after the merge).

Reexamine why you need it

Are you certain it will be helpful? If you feed that old Git log to ELK, would indexed search fit your colleagues (and yourself) better? With possibility of setting some dashboards in Kibana? Or if you set git instaweb on a machine with old repo, so that folks can browse it through web, will it perhaps meet your demands?

Consider git merge-repos

Never tried, so can't recommend, but it's apparently for just such an occasion and it was written when git-stitch-repo was young. May be worth checking out.

With some rewrite

There is also an option with some history rewrite, with git filter-branch. Probably can be done with BFG as well.