Re: [PATCH] Fix race and deadlock when sending pack
- From
Junio C Hamano <junkio@cox.net>
- Date
- Dec 19, 2005, 09:02 UTC
- Message-ID
- <7vvexlihmq.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <Pine.LNX.4.64.0512190130450.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> ... I don't think that it's actually a > good idea to have output to stdout from hooks go to git-send-pack's > stdout, since we may want to have git-send-pack report some sort of > information of its own to stdout,...
I admit that I haven't thought things through yet, but I do not offhand think of an argument against Paul's patch (a scenario that may be broken by the patch, that is), so I am inclined to take it, perhaps after hearing about the cpfd() thing I mentioned in the previous response to Paul.
It is conceivable that we may want to later extend the protocol so that the receiver can tell the sender the result of what happened to each of the ref-update request. Right now, the sender refuses to listen to what receiver says after it learns the current object names, but after pack transfer finishes and receiver decides what to do with each ref update request, we might want to add status, like this:
# Tell the pusher what commits we have and what their names are R: SHA1 name R: ... R: SHA1 name R: # flush -- it's your turn # Tell the puller what the pusher wants to happen S: old-SHA1 new-SHA1 name S: old-SHA1 new-SHA1 name S: ... S: # flush -- done with the list S: XXXXXXX --- packfile contents. # current protocol exchange ends here, but we could add...
# ... what happened to each ref-update request.
R: name OK
R: name FAIL
R: ...If we do something like this, we might want to say why things failed on "FAIL" line, and the output from hooks/update that prevented the ref-update would probably belong there.