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

> 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)?