Update for Git 2.23 (Q3 2019): "git push --atomic" that goes over the transport-helper (namely, the smart http transport) failed to prevent refs to be pushed when it can locally tell that one of the ref update will fail without
having to consult the other end, which has been corrected.
See commit 3bca1e7 (11 Jul 2019) by Emily Shaffer (nasamuffin).
(Merged by Junio C Hamano -- gitster -- in commit f87ee7f, 25 Jul 2019)
transport-helper: enforce atomic in push_refs_with_push
Teach transport-helper how to notice if skipping a ref during push would
violate atomicity on the client side.
We notice that a ref would be rejected, and choose not to send it, but don't notice that if the client has asked for --atomic we are violating atomicity if all the other pushes we are sending would succeed.
Asking the server end to uphold atomicity wouldn't work here as the server doesn't have any idea that we tried to update a ref that's broken.
The added test-case is a succinct way to reproduce this issue that fails today.
The same steps work fine when we aren't using a transport-helper to get to the upstream, i.e. when we've added a local repository as a remote:
git remote add ~/upstream upstream
Note: The atomic push over smart HTTP transport did not work, which has been corrected, with Git 2.24 (Q4 2019).
See commit 6f11942 (16 Oct 2019) by brian m. carlson (bk2204).
(Merged by Junio C Hamano -- gitster -- in commit d45d771, 23 Oct 2019)
remote-curl: pass on atomic capability to remote side
Signed-off-by: brian m. carlson
When pushing more than one reference with the --atomic option, the server is supposed to perform a single atomic transaction to update the references, leaving them either all to succeed or all to fail.
This works fine when pushing locally or over SSH, but when pushing over HTTP, we fail to pass the atomic capability to the remote side.
In fact, we have not reported this capability to any remote helpers during the life of the feature.
Now normally, things happen to work nevertheless, since we actually check for most types of failures, such as non-fast-forward updates, on the client side, and just abort the entire attempt.
However, if the server side reports a problem, such as the inability to lock a ref, the transaction isn't atomic, because we haven't passed the appropriate capability over and the remote side has no way of knowing that we wanted atomic behavior.
Fix this by passing the option from the transport code through to remote helpers, and from the HTTP remote helper down to send-pack.
With this change, we can detect if the server side rejects the push and report back appropriately.
Note the difference in the messages: the remote side reports "atomic transaction failed", while our own checking rejects pushes with the message "atomic push failed".
Document the atomic option in the remote helper documentation, so other implementers can implement it if they like.
So the Documentation/gitremote-helpers.txt now includes:
'option atomic' {'true'|'false'}:
When pushing, request the remote server to update refs in a single atomic transaction.
If successful, all refs will be updated, or none will.
If the remote side does not support this capability, the push will fail.
Before Git 2.27 (Q2 2020), "git push --atomic" used to show failures for refs that weren't even pushed, which has been corrected.
See commit dfe1b7f, commit f38b168, commit 46701bd, commit 865e23f, commit 7dcbeaa (17 Apr 2020) by Jiang Xin (jiangxin).
(Merged by Junio C Hamano -- gitster -- in commit 5b6864c, 28 Apr 2020)
send-pack: mark failure of atomic push properly
Signed-off-by: Jiang Xin
When pushing with SSH or other smart protocol, references are validated by function check_to_send_update() before they are sent in commands to send_pack() of "receve-pack".
For atomic push, if a reference is rejected after the validation, only references pushed by user should be marked as failure, instead of report failure on all remote references.
Commit v2.22.0-1-g3bca1e7f9f (transport-helper: enforce atomic in push_refs_with_push, 2019-07-11) wanted to fix report issue of HTTP protocol, but marked all remote references failure for atomic push.
In order to fix the issue of status report for SSH or other built-in smart protocol, revert part of that commit and add additional status for function atomic_push_failure().
The additional status for it except the "REF_STATUS_EXPECTING_REPORT" status are:
REF_STATUS_NONE : Not marked as "REF_STATUS_EXPECTING_REPORT" yet. REF_STATUS_OK : Assume OK for dryrun or status_report is disabled.
original answer (May 2016)
I am pushing to a BitBucket server
Only BitBucket support can confirm with you:
- their exact git version for their git hosting server
- if that feature was explicitly deactivated (
git config receive.advertiseatomic 0) or not.
I suspect it is not yet activated, as most git clients might not be at git 2.4 or more level that I mentioned in February 2015.
