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

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?

On Nov 27, 2007, at 7:49 PM, Junio C Hamano wrote:

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?

I didn't think the post-receive hook could reject a revision. I need  
to be able to do that here, e.g., if the user's change fails to commit  
because it's rejected by an svn commit hook. (Hooks upon hooks upon  
hooks...) If I do the svn commit in post-receive it's not clear how  
the user would repush the change after fixing it -- their fix would  
show up as a delta on top of a revision that I can't commit on its own  
to svn, so I would somehow have to know to do a squash merge and there  
would no longer be a one-to-one correspondence between git and svn  
revisions. That's not a total showstopper (I'm rewriting history  
anyway) but it sure seems like it'll be confusing and error-prone.

Also, running in post-receive will subject me to race conditions that  
aren't present in the update hook case; if I make my update hook  
script do its own locking and update the refs on its own, I'm  
guaranteed no other push will come along and update my ref out from  
under me. In post-receive there is no such guarantee and I may end up  
sending two pushes' worth of commits to svn when I think I'm only  
sending one.

If I'm misunderstanding the flow of control, please feel free to  
correct me. It just seemed like update was the only good place to do  
what I needed to do.

-Steve