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
On Fri, Aug 17, 2012 at 12:26 PM, John Arthorne
> 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:
> This is on git version 188.8.131.52.
> 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.
> John Arthorne
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html