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