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

[Patrick Steinhardt <ps@pks.im>]

On Thu, Jan 15, 2026 at 05:32:06AM -0800, Junio C Hamano wrote:
> 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.

Fair.

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

I dunno. I myself prefer converging towards a consistent coding style,
and part of that is to also adapt existing callers over time. One should
for sure be careful in this context and not go on a holy crusade against
all violations of our coding guidelines, but I still think there's a
point to be made that a slow trickle of changes of sleeping code is
fine.

In the case of these functions here I only did it because I was very
annoyed eventually. There is this mix where most of the functions
related to commit lists follow our guidelines, and only three of them
don't. The consequence is that you need to know by heart what the
exceptions are, and I got this wrong every second time and that
eventually made me write this small patch series.

If it's considered to be too invasive that's fine, then I'll drop it. I
think there's value though (well, obviously, otherwise I wouldn't have
sent the series :) ).

Thanks!

Patrick