On Wed, 25 Mar 2009, Junio C Hamano wrote: > 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? The current send-pack protocol wouldn't be able to use this feature (I don't think it can even report the replacement hashes, so there's little danger of that). The foreign VCS transport would actually reimport the objects (in the process of discovering the hash), so that's fine. > Otherwise I am afraid that you are corrupting the local repository. It wouldn't be any different from fetch() reporting success when it hadn't actually succeeded, but I think it would be worth being explicit here that you can't simply report the other end's hash if you may not have it. -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
