From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 28 Nov 2007 03:49:31 GMT
Subject: Re: [PATCH] Allow update hooks to update refs on their own
Message-ID: <7vzlwz9ghg.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <Pine.LNX.4.64.0711272143470.5349@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

> On Tue, 27 Nov 2007, Steven Grimm wrote:
>
>> On Nov 27, 2007, at 5:19 PM, Junio C Hamano wrote:
>> 
>> >How does this interact with the "pretend to have fetched back
>> >immediately" supported by modern git-push?
>> 
>> 
>> That continues to fire, but it updates the local tracking ref to point to the
>> SHA1 that was pushed, which isn't the actual remote ref. So you have to do a
>> real fetch to get the local tracking ref pointed to the right place. In other
>> words, that feature doesn't do any good in this context, but it doesn't really
>> hurt anything either.
>> 
>> It would of course be better if git-push could notice that it needs to do an
>> actual fetch. I think it'd be sufficient to transmit the final remote ref SHA1
>> back to git-push, and if it doesn't match what was pushed, that's a sign that
>> a fetch is needed. But that change wouldn't be mutually exclusive with this
>> patch, I believe.
>
> Couldn't you do this with a status message? ("ok <refname> changed by 
> hook" or something.)
>
> I disagree that the feature doesn't do any good; it records that the state 
> of the remote is at least as new as the local state, so you can tell 
> without a network connection that you don't have any local changes you 
> haven't sent off.

Yeah, and I am wondering why update hook needs to be changed for this.
Didn't we introduce post-receive exactly for this sort of thing?