Hi, On Fri, Mar 03, 2023 at 12:16:27AM -0800, Otto Kekäläinen wrote: > Hi! > > To summarize here: > > - Good git commit message titles should NOT end with a dot. Titles
I think there's consensus about that. > (and e.g. subject lines in an email) should not end with a dot based > on general English grammar rules and also software development / git > conventions as long as we have had patches and git commits. > > - By convention, many people use full sentences in changelogs (as > pointed out by e.g. Mattia in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959665). In a > changelog it makes sense to have full sentences if the texts are > longer. This is also what English grammar rules say: a (bullet point) > list with just titles are not sentences and have no trailing dot, but > if the list has longer and *some* items that are sentences, then all > items in the list should end with a dot. I think the reason this is not moving forward is that people have different preferences. "English grammar rule" seems to be interpreted differently e.g. by the Imperial college for their brand: https://www.imperial.ac.uk/brand-style-guide/writing/grammar/punctuation/bullet-points/ which would only use fulls top if there's an introductory sentence (which isn't usually the case for changelogs). And there's other recommendation all around. I think a good way to move this forward is to at least have a recommendation in the developers reference (if not in policy itself) as everyone can already have the changelog configured by `gbp dch` as they see fit (via a customization-file) already. > Therefore, can we please make sure that Lintian-brush and things that > do git commits do NOT add trailing space, and that tools that write > changelogs add trailing dots when needed? Note that 'gbp dch' already figures out if a dot is needed based on the commit body for *multiline* git commit messages. So the simplest thing would be to add yet another option that (optionally) does that for one line changelog messages as well which would break down the debate to what is the right default (for which developer reference and policy are usually strong indicators). I've added a note along those lines to #959665. Cheers, -- Guido
