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
Your mileage may vary and I may well have misunderstood the question and your intent, so I'll propose options with short summary:
Perl CPAN has git-stitch-repo, nice module that streamlines git fast-export
to git fast-import
.
Should linearize history.
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.
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).
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?
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.
There is also an option with some history rewrite, with git filter-branch. Probably can be done with BFG as well.