Jeff King <peff@xxxxxxxx> writes: > On Sun, Nov 05, 2006 at 11:37:08AM -0800, Junio C Hamano wrote: > >> I recall discussing this exact behaviour with Pasky when he >> added it to Cogito. I think we concluded that it is a very >> sensible thing to pretend we fetched immediately after we >> successfully pushed and got the same thing back, and there is no >> risk of data loss or user confusion, as long as we catch failure >> from the push and refrain from doing this update, which Cogito >> did implement correctly when we discussed this. > > Is it possible for hooks on the receiving side to change the tip commit > in some way? For example, the 'update' hook could do some markup on the > commit message or contents, creating a new commit and using it instead > of the pushed one; in this case, the sending side ends up with an > incorrect (and unrelated) SHA1. Is this simply too insane to worry > about? I do not think it is sane for the update hook to muck with tips in any way (they are meant for making policy decision whether to allow the push -- we do not enforce this, partly because the majorly lockless nature of git makes it impossible to, but then update hook is free to invoke "rm -rf $GIT_DIR" and nobody prevents it from doing so. It is the same kind of user shooting at his foot). The post-update hook is free to do anything what it wants. But that does not make the Cogito's "pretend we have fetched immediately after we pushed" semantics invalid. If the post-update hook rewinds the tip we just pushed, it is the same thing as in the case where the post-update hook did not do anything but somebody else, a human user, did the equivalent rewinding of the branch, and the pretended fetch happened between the time the push successfull finished and the time that somebody else did the rewinding, so this is nothing new. The next push would notice that the tip does not fast forward in either case. - 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