Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: >> > + * If, in the process, the transport determines that the >> > + * remote side actually responded to the push by updating the >> > + * ref to a different value, the transport should modify the >> > + * new_sha1 in the ref. (Note that this is a matter of the >> > + * remote accepting but rewriting the change, not rejecting it >> > + * and reporting that a different update had already taken >> > + * place) >> > + **/ >> >> It this even a sane thing to allow? How would it interact with the >> "pretend we immediately turned around and fetched them into the remote >> tracking branches" local updates we usually do? > > We already allow a git server to rewrite refs with a hook when it gets > them, and we record the pre-rewriting value. This allows the transport to > propagate the post-rewriting value back (if it can get it), and we'd > update the tracking branches with what the server actually did instead of > what we asked it to (i.e., we do what we would do if we really did turn > around and fetch them immediately). But how are you guaranteeing that objects necessary to complete the history the remote end re-written are already available on the local end? Do you have a reverse object transfer phase now in send-pack protocol? Otherwise I am afraid that you are corrupting the local repository. -- 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
