On Sat, 28 Apr 2007, Junio C Hamano wrote: > Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > > > We're not pretending anything; remote has confirmed that the head that the > > ref tracks has a particular new value (which we provided), so we should be > > able to update the tracking ref to that value. I don't think it's > > particularly important that we came by this information in the course of > > an exchange that wasn't a fetch. > > > > We are indeed pretending. Consider: > > (1) You push, and push succeeds. > > (2) Somebody fetches your result, works on it and pushes back; > this might happen in post-receive hook. > > (3) You fetch. You should see somebody else's commit at the > tip, not what you pushed in (1). > > By not fetching but instead of storing what you pushed, you are > pretending that you re-fetched so fast that you gave no chance > to anybody to perform (2) quickly enough. But you did effectively re-fetch instantaneously by doing an operation that atomicly updates the ref and reports success. If you consider the operation that updates tracking refs not to be necessarily "git-fetch" but rather "having a connection that discusses refs", this sequence isn't any different from (1) being a fetch instead of a push; there's always the chance that your interaction with the server is shortly before the ref values you update to being replaced, whether the operation you're doing is getting the remote's value or setting the remote's value. Even if a post-update hook further changes the ref you push to, it had better not change it to a non-descendant of the value you pushed, since there would be a race with other people fetching your value with the post-update hook is running and seeing history roll back. So, at worst, you could have the situation where, effectively, you *always* miss out on the latest thing, but it's already the case that you would *sometimes* miss out on the latest thing, if the post-update hook is running more slowly than your next fetch. The fact that the config option is "fetch" isn't really an argument that the way you have to get the knowledge of the value of the ref at the instant you remember locally has to be "git-fetch"; any way of getting knowledge of that value at some instant should suffice. -Daniel *This .sig left intentionally blank* - 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