Subject: Re: [PATCH 0/5] refs: remove functions without ref store

From: Junio C Hamano <[email-masked]>
Date: Mon, 06 May 2024 09:14:55 -0700

Patrick Steinhardt <[email-masked]> writes:

> It's also in line with how other subsystems behave. Everything relating
> to strbufs has a `strbuf_` prefix, attr-related code has `attr_` or
> `git_attr_`, mem-pool has `mem_pool_`. So ref-related code having a
> `ref_` prefix just feels natural to me.

OK.  This is a tangent but there are a few functions with strbuf_
prefix whose sole association with the strbuf is that it is the type
that happens to be used to store the operand of the operation (it is
like naming getenv() as str_getenv() or something silly like that).
We should rename them to lose their strbuf_ prefix in the longer
term.

> ... But honestly, I doubt
> that it would be faster for any author of a patch series to figure out
> that they now need to a define something compared to just adding the
> `refs_` prefix to their functions.

The authors would not bother figuring that out while your series is
not yet in 'master'.  The alternative they have is to base their
series on top of yours.  You may have "what changes are needed on
the callers side" in your head, but they don't.

Somebody brought up the approach used in <banned.h> to move the
problem to link time, but in the context the only message we are
giving is "it is banned - do not use it", which is sufficient over
there, but probably not in this context.  "it was removed - use this
instead by adding this suffix and add that as the first parameter"
is the message I want whoever needs to deal with the fallout to see.