Re: [PATCH 0/3] Rename commit list functions to conform to coding guidelines

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> I've been working with commit lists quite often recently, and every
> single time I get bitten by the fact that a subset of its functions do
> not conform to our coding guidelines. While most of the functions start
> with `commit_list_*()`, three functions don't. This patch series fixes
> this issue and renames the remaining three functions so that all of them
> start with `commit_list_*()`.

> Note that I'm adding compatibility wrappers for the old prototypes to
> ease the transition and not make life hard for any in-flight patch
> series. I've also dropped all changes that lead to conflicts with
> "seen".

Well, these are quite well established names, and seems to have
different callers between maint and master, which means that your
compatibility wrappers will need to stay there for some time because
these three patches will not apply to maint, leaving them in maint
under original names, and future fixes that involve maint, when
merged up to master and above, will still need these compatibility
wrappers.

Perhaps the new naming rules were introduced without surveying how
established names that follow different rules are and how often
they acquire more calling sites?  Should we instead tone down the
rules so that it says something like "when you are introducing new
type S, then call functions around it this way using S_ prefix",
leaving established names excempt (which is quite different from
letting sleeping dogs lie---as long as they acquire new callers and
the code that uses them change, they are not sleeping)?