Maxim Cournoyer <maxim.courno...@gmail.com> writes:
> Hi,
>
> Hilton Chain <hako@ultrarare.space> writes:
>
> [...]
>
>> If we ask new contributors to learn from the commit history, they are likely
>> to
>> find the inconsistency and feel confused. It would be better to have a
>> style in
>> the contribution documentation, the following for example:
>>
>> --8<---------------cut here---------------start------------->8---
>> scope: [changed module, procedure, variable etc. :] summary
>>
>> optional overview
>>
>> * file (variable) [changed part] {changed part, when [] is not sufficient}:
>> change.
>>
>> metadata (Fixes: , Reviewed-by: etc.)
>> --8<---------------cut here---------------end--------------->8---
>>
>> With short explanations and link to the coding standards for how to express
>> changes.
>
> It's not a bad idea, though I'm not sure if I'd want to enforce my
> personal preference (e.g., {} vs <>). It doesn't overly matter to me,
> especially now that it became more tedious to review the commit messages
> with Codeberg. I'll probably spend more time on what ultimately matters
> more (the diff), and I assume others will too.
If the exact convention in commit messages doesn't matter, I think we should say
so. What's needed in the contribution process should be made clear in the
documentation, so that most contributions can be considered finished only with
documented information. This is the eventual state I want to achieve in
<y7634bde07g.fsf@ultrarare.space>'s thoughts. I think I'll explain it more in
that thread.
> Maybe a GCD proposing modernizing what we put in our git commit messages
> could be devised; there are lots of good guidelines out there, such as
> those used by the Linux kernel and Git projects.
I think it doesn't overly matter for now too, since we can rely on committers to
do the decision. This topic is derived from the aforementioned one when I'm
thinking about it. If there's going to be a GCD, it need to be that one.
Thanks
