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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
