Re: git pull for update of netdev fails.

[Shawn Pearce <spearce@spearce.org>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.