Daniel Barkalow [off-list ref] 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 my conclusion is that this does not matter in practice, and
I am agreeing with what you tried to do. That does not change
the fact that we are pretending.
On Sat, 28 Apr 2007, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
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*