Preserving history; we often find ourselves using the git blame tool to discover why a certain change was made.

Preserving commit hashes; we use commit hashes in binary names and our issue tracker; ideally, these references remain intact.

In case you want to put project-a into a subdirectory, you can use git-filter-repo (filter-branch is discouraged)

Note: This rewrites history;

If you want the project's history to look as though all files have always been in the directory foo/bar, then you need to do a little surgery. Use git filter-branch with the "tree filter" to rewrite the commits so that anywhere foo/bar doesn't exist, it is created and all files are moved to it:

"that text has been removed from the official version on the Apache site." This itself is also not good. If you post "official" records but then quietly edit them over time, I have no choice but to assume bad faith in all the records I'm shown by you. Why should I believe anything Apache board members claim was "minuted" but which in fact it turns out they might have just edited into their records days, weeks or years later? One of the things I particularly watch for in modern news media (where no physical artefact captures whatever "mistakes" are published as once happened with newspapers) is whether when they inevitably correct a mistake they _acknowledge_ that or they instead just silently change things.

If the reality is you pushed out a release that doesn't even compile, and then you spotted the typo six minutes later, that's fine, that's what the git repo should show. Don't come to me asking if there's a way to change history so that it seems as if it didn't happen that way. How does that help anybody?

# Two commits are considered the same if they have the same tree and # the same commit and author metadata. This is how we re-identify # commits after their hash IDs have been rewritten.

What I think we're lacking is proper tooling, or at least the knowledge of it. I don't know what most people use to write Git commits, but concepts like interactive staging, rebasing, squashing, and fixup commits are very daunting with Git on the CLI, unless you know really well what you're doing. We should do a better job at learning people how to use tools like Git Tower (to give just one example) to rewrite Git history, and to produce nice Git commits.