One way to help this is to use some sort of tag text at the beginning of the commit info that is useful so you can see this in the sequence of commits that all go together (top is most recent commit):
sql_parser: add new languages now supported by parse_unicode()
sql_parser: switch from using old parse_text() to parse_unicode()
sql_parser: add parse_unicode()
sql_server_health: ....
sql_server_health: ....
...
rather than like:
fix stuff in this random function
updating functions using random function
The ones with the tags help the reader determine what things go together much more easily, so even those lame commits are much more helpful if they have a tag:
sql_parser: fix stuff in this random function
sql_parser: updating functions using random function
Yea the structure matches what you said but not really using the set of words called out in that example like "feat" "chore" etc.. Personally I find that less useful than categorized tags that the developers just choose as they go along and are meant as a thing to help you read the commit, not to actually fit into a perfect index of possible tags that are controlled someplace. Here's an example of the categorization scheme in use (plenty of other examples out there).
https://gitlab.freedesktop.org/mesa/mesa/-/commits/main
sql_parser: add new languages now supported by parse_unicode()
sql_parser: switch from using old parse_text() to parse_unicode()
sql_parser: add parse_unicode()
sql_server_health: ....
sql_server_health: ....
...
rather than like:
fix stuff in this random function
updating functions using random function
The ones with the tags help the reader determine what things go together much more easily, so even those lame commits are much more helpful if they have a tag:
sql_parser: fix stuff in this random function
sql_parser: updating functions using random function