summaryrefslogtreecommitdiff
path: root/compat
diff options
context:
space:
mode:
authorJunio C Hamano <gitster@pobox.com>2011-08-05 20:54:06 (GMT)
committerJunio C Hamano <gitster@pobox.com>2011-08-08 22:33:28 (GMT)
commit051e4005a37c4ebe8b8855e415e6c6969d68e1a3 (patch)
treef753bdf7fe6931e09d4e54f5a23024b1dc7739df /compat
parente9e0643fe64b613b6596b79b59df8ff10746f1a1 (diff)
downloadgit-051e4005a37c4ebe8b8855e415e6c6969d68e1a3.zip
git-051e4005a37c4ebe8b8855e415e6c6969d68e1a3.tar.gz
git-051e4005a37c4ebe8b8855e415e6c6969d68e1a3.tar.bz2
helping smart-http/stateless-rpc fetch race
A request to fetch from a client over smart HTTP protocol is served in multiple steps. In the first round, the server side shows the set of refs it has and their values, and the client picks from them and sends "I want to fetch the history leading to these commits". When the server tries to respond to this second request, its refs may have progressed by a push from elsewhere. By design, we do not allow fetching objects that are not at the tip of an advertised ref, and the server rejects such a request. The client needs to try again, which is not ideal especially for a busy server. Teach upload-pack (which is the workhorse driven by git-daemon and smart http server interface) that it is OK for a smart-http client to ask for commits that are not at the tip of any advertised ref, as long as they are reachable from advertised refs. Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'compat')
0 files changed, 0 insertions, 0 deletions