Patrick Steinhardt <ps@xxxxxx> 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.
