This is fixing for 'no whitespace around = for named parameters'
check-code rule.
check-code has overlooked this, because a file isn't recognized as one
to be checked (this problem is fixed by subsequent patch).
This is fixing for 'line too long' check-code rule.
check-code has overlooked this, because a file isn't recognized as one
to be checked (this problem is fixed by subsequent patch).
The old code did not understand the difference between the first line of the summary,
and a random line in the summary that happened to include a #, or a
random line in the changes that happened to include it.
7c3798ffdc0c is an example where it fails
The goal of commit summary keywords is to help us sort, categorize,
and filter our voluminous commits for our release notes in a way
that's helpful and meaningful to end users. Lately, there have been a
huge number of "keywords" that are neither words nor particularly key.
This patch tries to discourage that by narrowing the allowed
characters to alphanumeric. In particular, it doesn't allow "."
(method, function names, and file extensions) and "/" (filenames). It
also gives a short reminder of what a keyword ought to be.
The pull url header can easily grow over 80 chars. The check-commit script was
confusing this with a too long summary line. We update the regular expression to
not match other header.
\s is equivalent to the character class [ \t\n\r\f\v]. Using \s+ in
a regular expression against input with multiple lines may match across
multiple lines.
For the regexp in question, "\+\s+" would match "+\n " and similar
sequences, leading to false positives for functions that were included
in diff context, after a modified hunk.
The check-commit script search for "bug" withing bracket and ask people to use
(issueXXXX) instead. The test was too wide and matching any "(+b+u+g"sequence.
At the moment, check-commit will complain about the topic being capitalized,
but not the summary that comes after it. This diff corrects that deficiency.
