diff options
author | Ronnie Sahlberg <sahlberg@google.com> | 2014-04-28 14:36:15 -0700 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2014-09-03 10:04:14 -0700 |
commit | 6629ea2d4a5faa0a84367f6d4aedba53cb0f26b4 (patch) | |
tree | e8be3b6cc210bbb734ec84c8b7efe9a3cd68c843 /t/t5802-connect-helper.sh | |
parent | b4d75ac1d152bbab44b0777a4cc0c48db75f6024 (diff) | |
download | git-6629ea2d4a5faa0a84367f6d4aedba53cb0f26b4.tar.gz |
receive-pack.c: use a reference transaction for updating the refs
Wrap all the ref updates inside a transaction.
In the new API there is no distinction between failure to lock and
failure to write a ref. Both can be permanent (e.g., a ref
"refs/heads/topic" is blocking creation of the lock file
"refs/heads/topic/1.lock") or transient (e.g., file system full) and
there's no clear difference in how the client should respond, so
replace the two statuses "failed to lock" and "failed to write" with
a single status "failed to update ref". In both cases a more
detailed message is sent by sideband to diagnose the problem.
Example, before:
error: there are still refs under 'refs/heads/topic'
remote: error: failed to lock refs/heads/topic
To foo
! [remote rejected] HEAD -> topic (failed to lock)
After:
error: there are still refs under 'refs/heads/topic'
remote: error: Cannot lock the ref 'refs/heads/topic'.
To foo
! [remote rejected] HEAD -> topic (failed to update ref)
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t5802-connect-helper.sh')
0 files changed, 0 insertions, 0 deletions