Just to close the loop on this thread, it did turn out to be a permission problem in our case. It was difficult to track down because it was only a problem on one server in the cluster. Each server had a system git config file at /usr/local/etc/gitconfig. This was a symlink pointing to a single common config file at /etc/gitconfig. This real file had correct content and permissions, and all the machines where eclipse.org allows shell access had correct symlinks. So any tests on the command line always showed that the system config looked fine. However on git.eclipse.org, which is the machine with the central repositories we are pushing to, the symlink was missing o+rx. For security reasons this machine doesn't allow shell access, but our pushes to this machine were failing to honour the system configuration. I gather the patch prepared earlier in this thread will cause an error to be reported when the system config could not be read, which sounds like a good fix to help others track down problems like this. John Arthorne On Fri, Aug 17, 2012 at 12:26 PM, John Arthorne <arthorne.eclipse@xxxxxxxxx> wrote: > At eclipse.org we wanted all git repositories to disallow non-fastforward > commits by default. So, we set receive.denyNonFastForwards=true as a system > configuration setting. However, this does not prevent a non-fastforward > force push. If we set the same configuration setting in the local repository > configuration then it does prevent non-fastforward pushes. > > For all the details see this bugzilla, particularly comment #59 where we > finally narrowed this down: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=343150 > > This is on git version 1.7.4.1. > > The Git book recommends setting this property at the system level: > > http://git-scm.com/book/ch7-1.html (near the bottom) > > Can someone confirm if this is intended behaviour or not. > > Thanks, > John Arthorne -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html