]> git.ipfire.org Git - thirdparty/git.git/commit
send-pack: new return code "ERROR_SEND_PACK_BAD_REF_STATUS"
authorJiang Xin <zhiyou.jx@alibaba-inc.com>
Mon, 3 Feb 2025 06:29:36 +0000 (07:29 +0100)
committerJunio C Hamano <gitster@pobox.com>
Mon, 3 Feb 2025 23:24:57 +0000 (15:24 -0800)
commit3028db4af289560e670b9f362aea16eaf3d1825e
tree56a09a652917faacf09057fe6304b07c717980f3
parentdd69a12e6a6a4c55b7827238d7267fc2e75684d1
send-pack: new return code "ERROR_SEND_PACK_BAD_REF_STATUS"

The "push_refs" function in the transport_vtable is the handler for
git-push operation. All the "push_refs" functions for different
transports (protocols) should have the same behavior, but the behavior
of "git_transport_push()" function for builtin_smart_vtable in
"transport.c" (which calls "send_pack()" in "send-pack.c") differs from
the handler of the HTTP protocol.

The "push_refs()" function for the HTTP protocol which calls the
"push_refs_with_push()" function in "transport-helper.c" will return 0
even when a bad REF_STATUS (such as REF_STATUS_REJECT_NONFASTFORWARD)
was found. But "send_pack()" for Git smart protocol will return -1 for
a bad REF_STATUS.

We cannot ignore bad REF_STATUS directly in the "send_pack()" function,
because the function is also used in "builtin/send-pack.c". So we add a
new non-zero error code "SEND_PACK_ERROR_REF_STATUS" for "send_pack()".

Ignore the specific error code in the "git_transport_push()" function to
have the same behavior as "push_refs()" for HTTP protocol. Note that
even though we ignore the error here, we'll ultimately still end up
detecting that a subset of refs was not pushed in `transport_push()`
because we eventually call `push_had_errors()` on the remote refs.

Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-pack.c
send-pack.h
transport.c