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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux