Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > On Wed, 20 Sep 2006, Shawn Pearce wrote: > > 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 its not _that_ expensive. If the option is set to refuse non-fast forwards then you take the hit and do the check; if its set to allow them then you can bypass the check entirely and let the client direct it (like it does today). Speed vs. safety. I currently use "git rev-list $2..$1" in my update hooks to make sure the update is strictly a fast-foward type update for all branches. Enabling this option and having the check run in receive-pack would be faster than what I'm doing now (one less fork). > 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? Now that you say it, no. These two things (update hook and non-fast forward update) are unrelated. If the update hook wants to make the decision on a per branch basis then the option to allow a non-fast forward push must be enabled in the config file. > 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? Agree completely. -- Shawn. - 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