Hacker News Reader

Comment by Crito | Hacker News Reader

"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.

View on HN

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.

why not:

[receive] onlyFastForwards = true

The positive statement would be "onlyFastForwardMerges=true" or "mergesMustBeFastForward=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/

Reply on news.ycombinator.com