Re: git pull for update of netdev fails.

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 20, 2006, 21:37 UTC
Message-ID: <Pine.LNX.4.63.0609202333320.19042@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <20060920212747.GB24415@spearce.org>

Hi,

On Wed, 20 Sep 2006, Shawn Pearce wrote:

Show 21 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 20 Sep 2006, Shawn Pearce wrote:
> > 
> > > Of course an update hook finally took care of the problem, but having
> > > non fast-forward pushs be permitted on a shared, bare repository
> > > by default is interesting to say the least.  :-)
> > 
> > Unfortunately, it is send-pack making the decision on the client side, not 
> > receive-pack on the server side, the latter of which knows if the server 
> > side is shared or not.
> 
> Huh?
> 
> The server side update hook is given the old and new value of
> the ref by receive-pack; if it exists with a non-zero status the
> update fails.
> 
> The server side could also check if the current value in the ref
> (if it exists) is contained within the new value of the ref.  Yes,
> I know it doesn't today, but the point is it could.  And I was
> saying maybe it should when there is no update hook present.

The point being that this check is not necessarily inexpensive. But you are right, we could introduce this as a security measure. But is it really intuitive to skip this test when an update hook is added?

I'd rather set another config variable with --shared, which tells git to refuse receiving non-fast-forwards. This could be a sensible setting in other setups than shared ones after all. Thoughts?

Ciao, Dscho