Getting unified history/blame/diff across repositories?

Question

For reasons out of my control, I have two repositories (say, "R" and "S"), and code was moved from one repository to another. More specifically:

R:

Root ... a (add "code" folder) --- b (changes in "code") ... f (remove "code") ...

S:

Root ... a (add "code" removed from Rf) ... d (changes in "code") ...

Is there any way to easily:

• get a diff of the "code" pathspec between the repos, as if Rf and Sa are combined (and since they "cancel" each other out, didn't happen)? In other words, view a diff of "code" between Rb and Sd?

• view a "git blame" so to speak across repositories?

I am aware that theoretically I could filter-branch, pull that code out into a submodule, and reconstruct it, but such an occurrence has happened enough that doing so isn't feasible.

Answer 1

Git works with commits, not files. This makes your "get a diff" question easy, or even trivial: simply fetch the commits from one repository (or a clone thereof) to another. Fetching does not make any new commits, it just adds to the current repository all the commits that are in the fetched-from repository. So now you have, in the repository you're working in—a clone of either R or S—all of the R and S commits in a single repository, and now you can git diff Rb and Sd trivially.

Making git blame track backwards from Sa to Rf is harder, but if you're using a sacrificial clone,¹ you can use git replace --graft to "glue the histories together", so that Git doesn't really look at commit Sa at all. Instead, it looks at a replacement Sa' that's made by grafting to Rf as its parent. That's still not difficult, it just affects everyone using the clone (hence the need for a sacrificial one).

---

¹The fetch trick above can be done without a sacrificial clone, as the only thing it costs is disk space. The replace trick affects all users of the repository and thus is often unsuitable.