Git has a mechanism to declare two commits equal and replace one with the other: man git-replace

This comes at the cost of having intentionally multiple histories and is not well-suited for complicate cases, but for the common case of "we want to stitch this old CVS-history to this commit", it does a good job.

Usability-wise, replace refs are not cloned automatically and some web-based tools lack support for it.

You can also use the 'magic empty tree object' to make your repo more amenable to joining disparate histories of other trees. It requires both the source and destination repo to abide by this practice, but I do this on all of my repos...

Immediately after `git init`, do `git commit --allow-empty -m"initial empty commit"`. Now you have an empty commit, and any other repo which has this empty commit has some history in common with your repo.

The SHA-1 hash is well-known and there are plenty of articles you can find about it, if you search for 4b825dc642cb6eb9a060e54bf8d69288fbee4904

Here's one for example:

https://stackoverflow.com/questions/9765453/is-gits-semi-sec...

I'm not sure this helps for projects which have a shared development history, but not a shared commit history. But within an organization, where you have projects which may split and/or merge, it can help to bridge some gaps.

You can have unrelated commits and roots in a single git repo. No need for empty root commit.

I think the payoff is for merging unrelated histories, that you can then rebase one history on the other, and present a new unified history.

Is the really only reason why people do this, so that you can rewrite your initial working commit in a rebase? I think that might be it. (You can't easily rewrite the initial commit with a rebase.)