]> git.ipfire.org Git - thirdparty/git.git/commit
builtin/remote: cast away constness in `get_head_names()`
authorPatrick Steinhardt <ps@pks.im>
Fri, 7 Jun 2024 06:38:02 +0000 (08:38 +0200)
committerJunio C Hamano <gitster@pobox.com>
Fri, 7 Jun 2024 17:30:50 +0000 (10:30 -0700)
commit81654d27bf9e2f3745fb6190cb5b0863f91a644e
tree474cb4f985fe6f3c859325dda0daac091cd79913
parent235ac3f81ad1950f2e6b47b30561eb96844e1c85
builtin/remote: cast away constness in `get_head_names()`

In `get_head_names()`, we assign the "refs/heads/*" string constant to
`struct refspec_item::{src,dst}`, which are both non-constant pointers.
Ideally, we'd refactor the code such that both of these fields were
constant. But `struct refspec_item` is used for two different usecases
with conflicting requirements:

  - To query for a source or destination based on the given refspec. The
    caller either sets `src` or `dst` as the branch that we want to
    search for, and the respective other field gets populated. The
    fields should be constant when being used as a query parameter,
    which is owned by the caller, and non-constant when being used as an
    out parameter, which is owned by the refspec item. This is is
    contradictory in itself already.

  - To store refspec items with their respective source and destination
    branches, in which case both fields should be owned by the struct.

Ideally, we'd split up this interface to clearly separate between
querying and storing, which would enable us to clarify lifetimes of the
strings. This would be a much bigger undertaking though.

Instead, accept the status quo for now and cast away the constness of
the source and destination patterns. We know that those are not being
written to or freed, so while this is ugly it certainly is fine for now.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/remote.c