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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 16, 2026, 16:48 UTC
Message-ID: <xmqqikd1a4h5.fsf@gitster.g>
In-Reply-To: <aWngu0AZx5Akd_m0@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 6 quoted lines

> 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.

I do not think there is any disagreement here.

> 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 :) ).

Sure, if there were not other activities in the codebase, we can aim for perfection, but unfortunately we do not live in such an idealized world. Among the three patches, the first two that weighed only around 100 lines in fewer than 10 hunks are not bad at all, but the other one was a bit too much.

The linked list of commits is handy but not particularly performant data structure; instead of renaming component functions in the API, rewriting its users to use a better data structure might be a more productive way to achieve the same goal. There was a topic that gained quite a nice performance boost by rewriting code based on commit_list to use prio_queue, for example, in the recent past.