git - Restore history of divergent, then convergent repo -

i working on restoring history of codebase. have recovered commits lost @ root of git repo, , have discovered new complication.

a large chunk of code split separate codebase while... , merged in.

 main repo:  -- b -- c -- d -- e                   |         ^ code moved:       |         |                   v         | other repo:       x -- y -- z 

when split (and merge) occurred, files copied target repo, , history lost.

to complicate matters further, files modified on each copy before commit, it's need commit changes.

this leads me 2 questions:

will possible replace commit d (which copies files in) lower branch (x-y-z)? (this priority.)

if that's possible, possible restore history of files created @ commit x well?

there around 300 commits on "other" repo, , around 5000 on "main" repo d onwards.

i suspect git-rebase required, ideally, make use of git-filter-branch not have manually resolve historical merge conflicts.

you may want set git replace-ments surgically alter / splice history, without changing contents of existing commits. filter-branch discussed elsewhere, cause these replacement grafts become permanent.

because git replace lets substitute in 1 replacement object wherever git "see" original, , because commits have parent commit ids, can replace single commit chain of several commits. instance, if commit x "bad" in well-defined way:

...--o--p--x--q--o--... 

then construct new sequence of "good" commits g₁ ... g_n:

...--o--p--x--q--o--...          \           g1--g2--...--gn 

(where g₁'s parent commit id p, our bad x commit's parent; if x needs, or deserves, multiple parents, can set of in commit g₁). instruct git "replace" x g_n, traversal looks this:

...--o--p--x- [replaced]  -q--o--...          \               /           g1--g2--...--gn 

once filtered, x vanishes entirely, commits q , later being copied new copies in usual filter-branch fashion.

to construct "good" commits, can literally git checkout -b tempbranch <p> , start making commits, though if need set multiple parents bit more tricky (you can use git commit-tree instead of plain git commit, or cheat creating .git/merge_head remaining hashes in it). may want backdate new "good" commits, and/or set arbitrary authors (git commit has command line switches these, git commit-tree makes use magic env variables).