Re: receive.denyNonNonFastForwards not denying force update

From: Jeff King <peff@peff.net>
Date: Aug 21, 2012, 01:57 UTC
Message-ID: <20120821015738.GA20271@sigill.intra.peff.net>
In-Reply-To: <7v628dght9.fsf@alter.siamese.dyndns.org>

On Mon, Aug 20, 2012 at 06:22:26PM -0700, Junio C Hamano wrote:

Show 12 quoted lines

> > "git config --system receive.denynonfastforwards true" is not honored.
> >  At all.  (And I checked there was nothing overriding it).
> >
> > "--global" does work (is honored).
> >
> > Tested on 1.7.11
> 
> Thanks, and interesting.
> 
> Does anybody recall if this is something we did on purpose?  After
> eyeballing the callchain starting from cmd_receive_pack() down to
> receive_pack_config(), nothing obvious jumps at me.

No, I do not think it was on purpose. And it would be very hard to do so, anyway; config callbacks are not given any information about the source of the config variable, and cannot distinguish between repo, global, and system-level config variables.

> Could this be caused by a chrooted environment not having
> /etc/gitconfig (now I am just speculating)?

That seems far more likely to me. Another possibility is that the file is not readable by the user running receive-pack.

Show 5 quoted lines

> A quick "strace -f -o /tmp/tr git push ../neigh" seems to indicate
> that at least access() is called on "/etc/gitconfig" as I expect,
> which makes me think that near the beginning of git_config_early(),
> we would read from /etc/gitconfig if the file existed (I do not
> install any distro "git", so there is no /etc/gitconfig on my box).

I just did a few quick tests both across local repos and across an ssh session. receive.denynonfastforwards worked just fine in my /etc/gitconfig in both cases. So the likely cause would be that git cannot access that file for some reason (chroot or permissions).

-Peff