]> git.ipfire.org Git - thirdparty/git.git/commit
remote: always allocate branch.push_tracking_ref
authorJeff King <peff@peff.net>
Mon, 19 Jan 2026 05:23:20 +0000 (00:23 -0500)
committerJunio C Hamano <gitster@pobox.com>
Tue, 20 Jan 2026 00:24:02 +0000 (16:24 -0800)
commitd79fff4a11a527f57516c62fe00777852bab719a
tree43bde266e68d64e815c005d28f2beb0fd7d5012e
parent9bf9eed093561f50091014faa7164c0325ea9ced
remote: always allocate branch.push_tracking_ref

In branch_get_push(), we usually allocate a new string for the @{push}
ref, but will not do so in push.default=upstream mode, where we just
pass back the result of branch_get_upstream() directly.

This led to a hacky memory management scheme in e291c75a95 (remote.c:
add branch_get_push, 2015-05-21): we store the result in the
push_tracking_ref field of a "struct branch", under the assumption that
the branch struct will last until the end of the program. So even though
the struct doesn't know if it has an allocated string or not, it doesn't
matter because we hold on to it either way.

But that assumption was violated by f5ccb535cc (remote: fix leaking
config strings, 2024-08-22), which added a function to free branch
structs. Any struct which is fed to branch_release() is at risk of
leaking its push_tracking_ref member.

I don't think this can actually be triggered in practice. We rarely
actually free the branch structs, and we only fill in the
push_tracking_ref string lazily when it is needed. So triggering the
leak would require a code path that does both, and I couldn't find one.

Still, this is an ugly trap that may eventually spring on us. Since
there is only one code path in branch_get_push() that doesn't allocate,
let's just have it copy the string. And then we know that
push_tracking_ref is always allocated, and we can free it in
branch_release().

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote.c
remote.h