Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH] Fix race and deadlock when sending pack

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:15

Daniel Barkalow [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help