Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:54

Daniel Barkalow [off-list ref] writes:
On Tue, 27 Nov 2007, Steven Grimm wrote:
quoted
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.
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help