Re: Git commit message RFC
On 08/06/20 20:43, Kinney, Michael D wrote:
The main requirement is to make sure the Name: Value tag line for the nature of theI'd like to suggest "Type: " rather than "TYPE: ".
Furthermore, assuming a consistent use of the "Type: " name (at the
beginning of the line), do we really need the '**' value prefix/suffix?
On one hand, I find '**value**' a bit too "loud"; on the other, the
asterisk is a regexp special character, so it requires escaping with
backslash in git-log's "--grep" option argument, which makes it
uncomfortable. I think the lines:
would read very nice.
(I used the "refactoring" and "optimization" values as two (more
specific) replacements for the "**imp**" value -- "improvement of the
existing code logic without changing functionality".
Another one I can think of is "cleanup", but I think it's included under
At this time,
$ git log --oneline --grep='^Type: ' master
returns zero hits, so I think the '^Type: ' prefix makes these tags
unique, without the "**" value prefix/suffix.
Also, I think we should not combine multiple values on a single "Type: "
line. In practice, we've applied this "single-value" rule to all other
"Name: "s. (You have showed that "--all-match" matches multiple lines in
a commit message.)
Finally, I'd like to mention that "Type: fix" and "Type: feature" are
not always mutually exclusive. Sometimes, there are issues that cannot
be surgically / incrementally fixed and that call for a whole-sale
replacement (rewrite) of a function. I wouldn't go as far as
recommending "Type: rewrite" for this, I'm just saying that in some
(rare!) cases, "Type: fix" and "Type: feature" may both show up in the
same commit message. Like, we have a long-standing design issue that
emerges over time, and it gets replaced with new (better designed)
functionality. That's both a fix and a feature.