From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path:
ChangeLog entries are part of git commit messages and are automatically put
-into a corresponding ChangeLog file. A ChangeLog template can be easily generated
-with ./contrib/mklog.py
script. GCC offers a checking script that
-verifies a proper ChangeLog formatting (see git gcc-verify
git alias).
-for a particular git commit. The checking script covers most commonly used ChangeLog
+into a corresponding ChangeLog
file.
+A ChangeLog template can be easily generated by the
+./contrib/mklog.py
script. GCC offers a checking script that
+verifies proper ChangeLog formatting for a particular git commit
+(see the git gcc-verify
git alias).
+The checking script covers most commonly used ChangeLog
formats and the following paragraphs explain what it supports.
subject
- a brief description of the commitgit_description
- a leading text with git commit descriptionsign_off
- DCO sign-offcommitter_timestamp
- line with timestamp and an author name and email (2 spaces before and after name) 2020-04-23␣␣Martin Liska␣␣<mliska@suse.cz>
additional_author
- line with additional commit author name and email (starting with a tabular and 4 spaces) git_description
- optional; ends right before one of the other compoments is foundsubject
- a single line in the format described belowgit_description
- optional; ends right before one of the other components is foundsign_off
- optional; see DCO policycommitter_timestamp
- optional; when found before a changelog_file
, then it is added
to each changelog entryadditional_author
- optionalco_authored_by
- optional, can contain more than oneThe first line of the commit message contains a brief summary that
+encapsulates the intent of the change.
+For example: cleanup check_field_decls
.
+Although, very short, the summary should be distinct so that it will
+not be confused with other patches.
Ideally, the entire subject line should not exceed 75 characters.
+ +A component tag is a short identifier that identifies the part of +the compiler being modified. This highlights to the relevant +maintainers that the patch may need their attention. Multiple +components may be listed if necessary. Each component tag should be +followed by a colon. For example,
+ +libstdc++:
combine:
vax: testsuite:
Some large components may be subdivided into sub-components. If +the subcomponent name is not disctinct in its own right, you can use the +form component/sub-component:.
+ +The series identifier is optional and is only relevant if a number of +patches are needed in order to effect an overall change. It should be +a short string that identifies the series (it is common to all +commits in the series) and should be followed by a single dash surrounded +by white space.
+ +If your patch is related to a bug in the compiler for which there is an
+existing PR number, the bug number should be stated. Use the
+short-form variant [PRnnnnn]
without the bugzilla
+component identifier and with no space between 'PR' and the number.
+The body of the commit message should still contain the full form
+(PR <component>/nnnnn
) so that Bugzilla
+will correctly notice the commit.
+If your patch relates to two bugs, then write
+[PRnnnnn, PRmmmmm]
.
+For more than two bugs just cite the most relevant one in the summary
+and use an ellipsis after the first one; list all the
+related PRs in the body of the commit message in the full form.
It is not necessary to cite bugs that are closed as duplicates of +another unless there is something specific to a duplicate report that +is not covered by its parent bug.
+This patch adds a second movk pattern that models the instruction
+aarch64: Add an extra sbfiz pattern [PR87763]
+
+This patch adds a second movk pattern that models the instruction
as a "normal" and/ior operation rather than an insertion. It fixes
the third insv_1.c failure in PR87763, which was a regression from
GCC 8.
@@ -205,7 +272,11 @@ Co-Authored-By: Jack Bar <jack@example.com>
Tokenized patch
-$git_description
+$subject
+
+$git_description
+
+$sign_off
$committer_timestamp
diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index c0cce359..b879b2d5 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -243,29 +243,17 @@ can be accessed directly from the repository.)
E-mail subject lines
Your contribution e-mail subject line will become the first line of
-the commit message for your patch.
-
-A high-quality e-mail subject line for a contribution contains the
-following elements:
-
-
- - A classifier
- - Component tags
- - An optional series identifier
- - A brief summary
- - An optional bug number
-
-
-The entire line (excluding the classifier) should not exceed 75
-characters.
+the commit message for your patch, so should follow the same
+format,
+prefixed by a classifier.
Classifier
-The classifier identifies the type of contribution, for example a
-patch, an RFC (request for comments) or a committed patch (where
-approval is not necessary. The classifier should be written in upper
-case and surrounded with square brackets. This is the only component
-of the e-mail subject line that will not appear in the commit itself.
+
The classifier identifies the type of contribution, for example a patch,
+an RFC (request for comments) or a committed patch (where approval is not
+necessary). The classifier should be surrounded with square brackets,
+and is often written all upper case. This is the only component of the
+e-mail subject line that will not appear in the commit itself.
The classifier may optionally contain a version number (vN) and
a series marker (N/M). Examples are:
@@ -275,61 +263,9 @@ a series marker (N/M). Examples are:
[PATCH 3/7]
- the third patch in a series of seven
patches
[RFC]
- a point of discussion, may contain a patch
- [COMMITTED]
- a patch that has already been committed.
-
A component tag is a short identifier that identifies the part of -the compiler being modified. This highlights to the relevant -maintainers that the patch may need their attention. Multiple -components may be listed if necessary. Each component tag should be -followed by a colon. For example,
- -libstdc++:
combine:
vax: testsuite:
[committed]
- a patch that has already been committed.Some large components may be subdivided into sub-components. If -the subcomponent name is not disctinct in its own right, you can use the -form component/sub-component:.
- -The series identifier is optional and is only relevant if a number of -patches are needed in order to effect an overall change. It should be -a short string that identifies the series (it is common to all -patches) and should be followed by a single dash surrounded by white -space.
- -The brief summary encapsulates in a few words the intent of the
-change. For example: cleanup check_field_decls
.
-Although, very short, the summary should be distinct so that it will
-not be confused with other patches.
If your patch relates a bug in the compiler for which there is an
-existing PR number the bug number should be stated. Use the
-short-form variant [PRnnnnn]
without the bugzilla
-component identifier and with no space between 'PR' and the number.
-The body of the commit message should still contain the full form
-(PR <component>/nnnnn
) within the body of
-the commit message so that Bugzilla will correctly notice the
-commit. If your patch relates to two bugs, then write
-[PRnnnnn, PRmmmmm]
. For multiple
-bugs, just cite the most relevant one in the summary and use an
-elipsis instead of the second, or subsequent PR numbers; list all the
-related PRs in the body of the commit message in the normal way.
It is not necessary to cite bugs that are closed as duplicates of -another unless there is something specific to that report that -is not covered by the parent bug.
-Some large patch sets benefit from an introductory e-mail that @@ -362,7 +298,7 @@ original thread indicating that a new version has been submitted.
Here are some complete examples, based on real commits to GCC.
[COMMITTED] libstdc++: Fix freestanding build [PR92376]
[committed] libstdc++: Fix freestanding build [PR92376]
[PATCH 1/6] analyzer: Fix tests for UNKNOWN_LOCATION
[RFC] doc: Note that some warnings depend on optimizations [PR92757]
[COMMITTED] c++: coroutines - Initial implementation