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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 15, 2026, 13:32 UTC
Message-ID: <xmqqa4yfdmsp.fsf@gitster.g>
In-Reply-To: <20260115-pks-commit-list-coding-guidelines-v1-0-c58868dbf412@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 6 quoted lines

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