Re: git pull for update of netdev fails.

From: Shawn Pearce <spearce@spearce.org>
Date: Sep 20, 2006, 21:49 UTC
Message-ID: <20060920214903.GF24415@spearce.org>
In-Reply-To: <Pine.LNX.4.63.0609202333320.19042@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 7 quoted lines

> 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.