"Git", (really, whatever git server you are using for your publicly accessible repo) only allows you to do that if you allow it to allow you to do that. Rejecting non-fast-forward commits is standard practice in every git shop that I've worked in.

It's also the default these days.

    $ git init --bare --shared foo.git
    Initialized empty shared Git repository in foo.git/

    $ cat foo.git/config 
    # ...
    [receive]
    	denyNonFastforwards = true

I love just how persistent is Git in confusing users. Double negative, anyone?

It's not a double negative...denying non-FFs != allowing FFs.

The positive statement would be "onlyFastForwardMerges=true" or "mergesMustBeFastForward=true"

why not:

[receive] onlyFastForwards = true

We use git rewriting extensively and do allow non-FF commits. We also have process and tools in place such that master is held sacred (and our live branch is untouchable). Every once in a blue moon, a master branch will get a non-FF, and our tooling is such that we make sure everyone knows it happened.

However, we are a small team consisting of mostly Linux kernel developers, so that may influence the level of trust we put in not screwing things up. We also work pretty much independently; were that not the case, this would get ugly.

> However, we are a small team consisting of mostly Linux kernel developers

What team is that, and what are you working on?

Oracle Ksplice[1]: patches the kernel with security updates without rebooting.

1. http://www.ksplice.com/