3 ms·

Exactly! The fact that Git allows you to destructively rewrite history public history is EVIL. Not every user of revision control is going to have a Phd in Not

Exactly! The fact that Git allows you to destructively rewrite history public history is EVIL. Not every user of revision control is going to have a Phd in Not Fucking Up The Repo and I never want a situation like the Jenkins devs had[1] to occur with my projects. [1] https://news.ycombinator.com/item?id=6713742 https://news.ycombinator.com/item?id=6713742

Crito 12y ago
"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.
- davvid 12y ago
  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
  - anton_gogolev 12y ago
    I love just how persistent is Git in confusing users. Double negative, anyone?
    - tsm 12y ago
      It's not a double negative...denying non-FFs != allowing FFs.
      - pdhborges 12y ago
        why not: [receive] onlyFastForwards = true
      - timv 12y ago
        The positive statement would be "onlyFastForwardMerges=true" or "mergesMustBeFastForward=true"
- SoftwareMaven 12y ago
  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.
  - JoshTriplett 12y ago
    > However, we are a small team consisting of mostly Linux kernel developers What team is that, and what are you working on?
    - SoftwareMaven 12y ago
      Oracle Ksplice[1]: patches the kernel with security updates without rebooting. 1. http://www.ksplice.com/ http://www.ksplice.com/

Crito 12y ago

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

davvid 12y ago
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
- anton_gogolev 12y ago
  I love just how persistent is Git in confusing users. Double negative, anyone?
  - tsm 12y ago
    It's not a double negative...denying non-FFs != allowing FFs.
    - pdhborges 12y ago
      why not: [receive] onlyFastForwards = true
    - timv 12y ago
      The positive statement would be "onlyFastForwardMerges=true" or "mergesMustBeFastForward=true"
SoftwareMaven 12y ago
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.
- JoshTriplett 12y ago
  > However, we are a small team consisting of mostly Linux kernel developers What team is that, and what are you working on?
  - SoftwareMaven 12y ago
    Oracle Ksplice[1]: patches the kernel with security updates without rebooting. 1. http://www.ksplice.com/ http://www.ksplice.com/