Strategy for preventing or catching git history rewrite

Question

Although I love the git history rewrite feature, how does one go about ensuring history isn't rewritten.

We dont mind what a programmer does on their own machine, but we need to ensure that a version is not pushed to the server that changes history.

ie We need to guarantee that a particular version from the past really was that version. So this would include preventing someone going through and permanently removes a file from the history, or permanently alters a file throughout all history.

Answer 1

If you can run:

 git config --system receive.denyNonFastforwards true

on the server, that should take care of rewriting history case being pushed to said server.
However that is for the all repo, not for a specifc file or group of files.

git config:

receive.denyNonFastForwards

If set to true, git-receive-pack will deny a ref update which is not a fast-forward. Use this to prevent such an update via a push, even if that push is forced. This configuration variable is set when initializing a shared repository.

---

As ebneter (who knows the importance of a coherent repository -- see the answer about SVN to Git migrations) comments:

You might want to also add receive.denyDeletes true because otherwise, someone can just delete the branch and then push their rewritten one as a new branch, effectively rewriting history.

git config:

If set to true, git-receive-pack will deny a ref update that deletes the ref. Use this to prevent such a ref deletion via a push.

Answer 2

If you aren't using a new enough git for receive.denyNonFastForwards, you can enforce the policy through {pre,post}-receive (among others) hooks on the server, which allows a little bit more granularity for specific branches and so forth. Some good examples (including one prohibiting overwriting history) are used by the GNOME project to manage all of the repositories there:

http://git.gnome.org/browse/gitadmin-bin/tree/

I'd look in particular at pre-receive-check-policy.