Re: [PATCH] Allow update hooks to update refs on their own

How does this interact with the "pretend to have fetched back
immediately" supported by modern git-push?

On Tue, 27 Nov 2007, Steven Grimm wrote:

On Nov 27, 2007, at 5:19 PM, Junio C Hamano wrote:

quoted

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.

	-Daniel
*This .sig left intentionally blank*

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.

-Steve

On Tue, Nov 27, 2007 at 10:25:32PM -0500, Daniel Barkalow wrote:

quoted

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

Having just touched this code, I believe the answer is yes. receive-pack
has always sent just "ok <refname>\n", so we could start interpreting
anything after the <refname> bit freely (I think "ok <refname>
changed-to <hash>" is even more informative, but perhaps not useful
given that the sender probably doesn't have that commit object).

-Peff