Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When you're kind of fresh with Git (and DVCS in general), and you start exploring history-rewriting changes, you're safe if the repository is only local, but you might run into problems if you work with remotes and try to push such changes.

A feature that I'd expect is the ability to enable a "safe mode" which would basically stop me from doing whatever I shouldn't do... And what do I mean by that? I mean history-rewriting changes for things already pushed to an origin. I can't define it precisely, but this would include such cases as:

  • commit --amend when HEAD has been already pushed
  • rebase of a non-local branch
  • reset of a branch that has been pushed

These are examples of situations which will will probably make the next push fail (because it wouldn't be fast-forward, IIRC). I've made some of that by accident and had to re-create the branch on the remote. And I still was lucky to do this fast enough so that nobody pulled the history I've rewritten.

I believe it's possible to identify this type of changes and, on demand, prevent the user from making them. Is there perhaps an option for that?

If there isn't, do you think it's worthwhile to attempt to create it? Would you try to define precisely how to identify such a "dangerous change"?

share|improve this question
In a work environment in which committing bad changes affects other programmers, you should probably be more reluctant to perform these actions unless you're sure it's something that should work. Even then, you should verify that no problems persist afterwards. Imagine that a few years ago, I was in a team of many programmers in which one would have no qualms committing source that did not compile! I wanted to shoot him dead after 3 months of that. – Neil Apr 20 '12 at 10:04
It seems reasonable you could detect this in a hook on the remote machine and then reject the changes. – Andrew T Finnell Apr 20 '12 at 10:21
See… – ChrisF Apr 20 '12 at 11:26
I don't get your question. The default mode is safe. It won't allow you to push, unless you specify --force. – Let_Me_Be Apr 20 '12 at 14:58
I'd like to see something like this too. Basically I'd like to provide those learning git a safer version, probably by just wrapping the command line and only exposing the basics: commit, pull, push, simple stuff. Force them out to full git for anything on this page: Git is already a little harder to learn than other tools for having a local and remote repo to think about - worrying you might rebase instead of rollback is scary. – Chris Moschini Sep 3 '13 at 18:23

This looks very close, if not the same question as Strategy for Preventing or Catching Git History Rewrite

To sum it up you can enable

git config --system receive.denyNonFastforwards true


git config --system receive.denyDeletes true

Or write a post receive hook to reject anything you determine is a rewrite.

share|improve this answer
I believe denyNonFastforwards is the default (?), while denyDeletes isn't. These two are useful, but I'm imagining a client-side solution that would stop me from i.e. doing a commit --amend if I'd be unable to push it (because HEAD was already pushed). – Kos Apr 20 '12 at 15:52
In other words: In addition to the mechanisms that allow to keep a remote consistent, I'd like something that allows to keep a clone "consistent" with a remote too. – Kos Apr 20 '12 at 15:53
@Kos You can create local hooks also – Andrew T Finnell Apr 20 '12 at 17:29
Is there a way to set denyNonFastfowards to true only on the master branch? I'd like my topic branches to be allowed to be rebased and force-pushed. – nnyby Jan 18 '15 at 23:40

No because it s part of the philosophy of git to give you full power and let you manage that power the way you want.

If you dont adhere to this philosophy, then maybe switching to Mercurial would be worth as they allow rewriting history but in a limited or, to be clear, reluctant way, that makes you feel it is not a good idea.

share|improve this answer
I make mistakes. A mechanism that requires me to confirm explicitly whenever I'm doing something dangerous is something that seems to fit into "managing my power the way I want". :-) (Also Git already does that on occasions.) – Kos Apr 20 '12 at 9:31

AFAIK, the way git solves these issues is that whenever you request such an action, it will perform it locally, but inform you that what you are doing may have undesirable consequences. At that point, you haven't pushed anything yet, so you are in a position to review your local repository, and possibly undo the dangerous change before you push. You do have to pay attention to what git is telling you though, and you better be careful when you repair such errors.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.