Hi, On Wed, 20 Sep 2006, Shawn Pearce wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 - 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