Re: [PATCH 2/5] Document details of transport function APIs

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 25, 2009, 18:03 UTC
Message-ID: <7vmyb95vky.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LNX.1.00.0903251142470.19665@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 19 quoted lines

>> > +	 * 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.