Commit Comments - Revision history

Adilger: /* Test-Parameters: tag */ refined `trivial` coverage, fixed typos

2026-10-24T06:17:40Z

Test-Parameters: tag: refined `trivial` coverage, fixed typos

← Older revision		Revision as of 22:17, 23 October 2026
Line 90:		Line 90:
	There is a page dedicated to describe the <code>Test-Parameters:</code>, see [https://wiki.whamcloud.com/display/PUB/Changing+Test+Parameters+with+Gerrit+Commit+Messages Changing Test Parameters with Gerrit Commit Messages], but some examples of common parameters include:		There is a page dedicated to describe the <code>Test-Parameters:</code>, see [https://wiki.whamcloud.com/display/PUB/Changing+Test+Parameters+with+Gerrit+Commit+Messages Changing Test Parameters with Gerrit Commit Messages], but some examples of common parameters include:

	; <code>Test-~~Parmeters~~: trivial</code> : ~~patch does not affect code functionality,~~ run only build and ~~smoke test~~		; <code>Test-Parameters: trivial</code> : run a reduced set of tests instead of the full set; use this for test-only, documentation and build changes, and for low-risk code changes whose effect is fully covered by <code>sanity</code> or <code>sanity-lnet</code>, or by the patch's own new or changed tests
	; <code>Test-~~Paramters~~: testlist=sanity env=ONLY=102,ONLY_REPEAT=100</code> : run <code>sanity.sh test_102</code> 100 times in a loop, in addition to regular tests		; <code>Test-Parameters: testlist=sanity env=ONLY=102,ONLY_REPEAT=100</code> : run <code>sanity.sh test_102</code> 100 times in a loop, in addition to regular tests
	; <code>Test-~~Paramters~~: testlist=sanity clientarch=aarch64 clientdistro=rocky9.5</code> : run <code>sanity.sh</code> on a rocky9.5 aarch64 client, in addition to regular tests		; <code>Test-Parameters: testlist=sanity clientarch=aarch64 clientdistro=rocky9.5</code> : run <code>sanity.sh</code> on a rocky9.5 aarch64 client, in addition to regular tests

	==AI/LLM/Tool Attribution==		==AI/LLM/Tool Attribution==

Adilger: /* Patches ported from master to upstream kernel */

2026-10-01T08:27:16Z

Patches ported from master to upstream kernel

← Older revision		Revision as of 00:27, 1 October 2026
Line 277:		Line 277:
	invalidated after revalidation is finished.		invalidated after revalidation is finished.

	Reviewed-on: ~~http~~://review.whamcloud.com/7475		Reviewed-on: https://review.whamcloud.com/7475
	Lustre-bug-id: https://jira.whamcloud.com/browse/LU-3544		Lustre-bug-id: https://jira.whamcloud.com/browse/LU-3544
	Change-Id: I7700cbaddc4ec08e12c9f7d8021783a6135dd35a		Change-Id: I7700cbaddc4ec08e12c9f7d8021783a6135dd35a

Adilger: /* Patches ported from master to maintenance branch */

2026-10-01T08:17:48Z

Patches ported from master to maintenance branch

← Older revision		Revision as of 00:17, 1 October 2026
Line 245:		Line 245:

	Lustre-commit: 4e308ef74f271ec7e19917e3c0f88586537582c3		Lustre-commit: 4e308ef74f271ec7e19917e3c0f88586537582c3
	Lustre-change: ~~http~~://review.whamcloud.com/9538		Lustre-change: https://review.whamcloud.com/9538

	LU-4725 obd: lu_object_find_at hung		LU-4725 obd: lu_object_find_at hung
Line 254:		Line 254:

	Lustre-commit: b7c72ec1ddeda2cf94ea151f974d3f94e3a7d1ed		Lustre-commit: b7c72ec1ddeda2cf94ea151f974d3f94e3a7d1ed
	Lustre-change: ~~http~~://review.whamcloud.com/10484		Lustre-change: https://review.whamcloud.com/10484
	Xyratex-bug-id: MRP-1700		Xyratex-bug-id: MRP-1700

Adilger: /* Patch porting examples */ improve description to be consistent with AGENTS.md

2026-10-01T08:10:25Z

Patch porting examples: improve description to be consistent with AGENTS.md

← Older revision		Revision as of 00:10, 1 October 2026
Line 230:		Line 230:
	* the '''original''' <code>Reviewed-by:</code> lines can be kept, and Gerrit will automatically add them as reviewers to the new patch		* the '''original''' <code>Reviewed-by:</code> lines can be kept, and Gerrit will automatically add them as reviewers to the new patch
	* the <code>Tested-by: Maloo</code> and <code>Tested-by: Jenkins</code> lines should be removed from the new commit message, though any <code>Tested-by:</code> lines from real people can be kept		* the <code>Tested-by: Maloo</code> and <code>Tested-by: Jenkins</code> lines should be removed from the new commit message, though any <code>Tested-by:</code> lines from real people can be kept
	* the <code>Reviewed-on: ~~http~~://review.whamcloud.com/nnnnn</code> line should be changed to <code>Lustre-change: ~~http~~://review.whamcloud.com/nnnnn</code> (please use the "permalink" Gerrit URL format as shown)		* the <code>Reviewed-on: https://review.whamcloud.com/c/fs/lustre-release/+/nnnnn</code> line should be changed to <code>Lustre-change: https://review.whamcloud.com/nnnnn</code> (please use the short "permalink" Gerrit URL format as shown, which is the only form accepted by the <code>commit-msg</code> hook)
	* the <code>cherry picked from commit ca09fda138b6d72588f40e4cf79c5f2de832d2dd</code> line should be changed to <code>Lustre-commit: ca09fda138b6d72588f40e4cf79c5f2de832d2dd</code>		* the <code>cherry picked from commit ca09fda138b6d72588f40e4cf79c5f2de832d2dd</code> line should be changed to <code>Lustre-commit: ca09fda138b6d72588f40e4cf79c5f2de832d2dd</code>
	* any non-trivial changes to the original patch should be described after the original <code>Signed-off-by:</code> and <code>Lustre-commit:</code> lines before your own <code>Signed-off-by:</code> line		* any non-trivial changes to the original patch should be described after the original <code>Signed-off-by:</code> and <code>Lustre-commit:</code> lines before your own <code>Signed-off-by:</code> line

Adilger: /* Additional commit tags */ improve description to be consistent with AGENTS.md

2026-10-01T08:07:43Z

Additional commit tags: improve description to be consistent with AGENTS.md

← Older revision		Revision as of 00:07, 1 October 2026
Line 109:		Line 109:
	==Additional commit tags==		==Additional commit tags==

	A number of additional commit tags can be used to further explain who has contributed to the patch, and for tracking purposes. These tags are commonly used with Linux kernel patches. These tags should appear before the <code>Signed-off-by:</code> tag.		A number of additional commit tags can be used to further explain who has contributed to the patch, and for tracking purposes. These tags are commonly used with Linux kernel patches. These tags should appear before the <code>Signed-off-by:</code> tag (only <code>Assisted-by:</code> goes after it, as described above).

	Acked-by: User Name <user@domain.com>		Acked-by: User Name <user@domain.com>
Line 120:		Line 120:
	CoverityID: nnnnnn ("type of issue")		CoverityID: nnnnnn ("type of issue")
	{Organization}-bug-id: arbitrary bug tracking identifier		{Organization}-bug-id: arbitrary bug tracking identifier
	Lustre-change: https://~~jira~~.whamcloud.com/~~browse/LU-~~nnnnn		Lustre-change: https://review.whamcloud.com/nnnnn
	Lustre-commit: {full git commit hash of master patch}		Lustre-commit: {full git commit hash of master patch}
	Linux-commit: {full git commit hash of upstream kernel patch}		Linux-commit: {full git commit hash of upstream kernel patch}

Adilger: /* AI/LLM/Tool Attribution */

2026-10-01T08:02:47Z

AI/LLM/Tool Attribution

← Older revision		Revision as of 00:02, 1 October 2026
Line 98:		Line 98:
	Per the Linux kernel coding policy, patches that are substantially developed or assisted by AI/LLM Agents, coding assistants, or similar code-generation tools should be properly attributed. This helps track the evolving role of AI in the development process. Contributions should include an <code>Assisted-by:</code> tag after the <code>Signed-off-by:</code> tag in the following format:		Per the Linux kernel coding policy, patches that are substantially developed or assisted by AI/LLM Agents, coding assistants, or similar code-generation tools should be properly attributed. This helps track the evolving role of AI in the development process. Contributions should include an <code>Assisted-by:</code> tag after the <code>Signed-off-by:</code> tag in the following format:

	Assisted-by: AGENT_NAME:MODEL_VERSION [~~TOOL1] [TOOL2~~]		Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL ...]

	Where:		Where:
	* <code>~~AGENT_NAME~~</code> is the ~~name of the AI tool or framework~~		* <code>MODEL_ID</code> is the model ID as reported by the model's API
	* <code>MODEL_VERSION</code> is the ~~specific~~ model ~~version used~~		* <code>[TOOL...]</code> are optional specialized analysis tools used, separated by spaces (e.g., <code>coccinelle</code>, <code>sparse</code>, <code>smatch</code>, <code>clang-tidy</code>, <code>ltvm</code>, <code>llm_code_and_review_tools</code>)
	* <code>[~~TOOL1]</code>, <code>[TOOL2~~]</code> are optional specialized analysis tools used (e.g., <code>coccinelle</code>, <code>sparse</code>, <code>smatch</code>, <code>clang-tidy</code>, <code>ltvm</code>, <code>llm_code_and_review_tools</code>)		Basic development tools (<code>git</code>, <code>gcc</code>, <code>make</code>, <code>editors</code>) should not be listed. For example:
	Basic development tools (<code>git</code>, <code>gcc</code>, <code>make</code>, <code>editors</code>) should not be listed.
			Assisted-by: ClaudeCode:claude-opus-5-5 ltvm llm_code_and_review_tools

	==Additional commit tags==		==Additional commit tags==

Adilger: /* Fixes tag */

2026-10-01T07:54:54Z

Fixes tag

← Older revision		Revision as of 23:54, 30 September 2026
Line 72:		Line 72:
	and then running any git logging command (including with <code>-S</code> or <code>--grep</code> to search for patches):		and then running any git logging command (including with <code>-S</code> or <code>--grep</code> to search for patches):

	$ git log -1 --pretty=fixes ~~b1acf734f3~~		$ git log -1 --pretty=fixes b1acf734f31c

	or directly from your editor (vim, of course) to insert the line into the commit message:		or directly from your editor (vim, of course) to insert the line into the commit message:
Line 80:		Line 80:
	This will produce a line that is suitable for inclusion directly into the commit message, for example:		This will produce a line that is suitable for inclusion directly into the commit message, for example:

	Fixes: ~~b1acf734f3~~ ("LU-13468 fld: repeat rpc in fld_client_rpc after EAGAIN")		Fixes: b1acf734f31c ("LU-13468 fld: repeat rpc in fld_client_rpc after EAGAIN")

	==Test-Parameters: tag==		==Test-Parameters: tag==

Adilger: /* The Change-Id: line and Code Style */ improve description to be consistent with AGENTS.md

2026-10-01T07:52:26Z

The Change-Id: line and Code Style: improve description to be consistent with AGENTS.md

← Older revision		Revision as of 23:52, 30 September 2026
Line 56:		Line 56:
	The <code>Change-Id:</code> field is inserted automatically into the commit message by installing the <code>contrib/git-hooks/commit-msg</code> hook into each Git repository's <code>.git/hooks/</code> directory. The <code>contrib/git-hooks/prepare-commit-msg</code> script should be installed as well. From the top-level Lustre tree checkout:		The <code>Change-Id:</code> field is inserted automatically into the commit message by installing the <code>contrib/git-hooks/commit-msg</code> hook into each Git repository's <code>.git/hooks/</code> directory. The <code>contrib/git-hooks/prepare-commit-msg</code> script should be installed as well. From the top-level Lustre tree checkout:

	$ ln -sf ../../contrib/git-hooks/~~commit-msg .git/hooks/~~		$ ln -sf ../../contrib/git-hooks/{prepare-,}commit-msg .git/hooks/
	~~$ ln -sf ../../contrib/git-hooks/~~prepare-commit-msg .git/hooks/

	At <code>git commit</code> time this will run the <code>.git/hooks/prepare-commit-msg</code> script from the currently Lustre tree to check the code changes for style errors using <code>contrib/checkpatch.pl</code>, and add comments at the end of the commit message with any warnings or errors. After the commit message has been saved, the <code>.git/hooks/commit-msg</code> script will verify that the commit message format matches the format specified above, and insert the <code>Change-Id:</code> field into the commit message, if one isn't already present. Using a symlink instead of copying the hooks will ensure that the hooks are updated appropriately between branches and as changes are made to the scripts.		At <code>git commit</code> time this will run the <code>.git/hooks/prepare-commit-msg</code> script from the currently Lustre tree to check the code changes for style errors using <code>contrib/scripts/checkpatch.pl</code>, and add comments at the end of the commit message with any warnings or errors. After the commit message has been saved, the <code>.git/hooks/commit-msg</code> script will verify that the commit message format matches the format specified above, and insert the <code>Change-Id:</code> field into the commit message, if one isn't already present. Using a symlink instead of copying the hooks will ensure that the hooks are updated appropriately between branches and as changes are made to the scripts.

	If a patch needs to be resubmitted for some reason (e.g. original patch was landed, then reverted), the original <code>Change-Id:</code> should be referenced as <code>Was-Change-Id:</code> so that it is possible to correlate these patches together in the future.		If a patch needs to be resubmitted for some reason (e.g. original patch was landed, then reverted), the original <code>Change-Id:</code> should be referenced as <code>Was-Change-Id:</code> so that it is possible to correlate these patches together in the future.

Adilger: /* The Signed-off-by: line */ improve description to be consistent with AGENTS.md

2026-10-01T07:49:14Z

The Signed-off-by: line: improve description to be consistent with AGENTS.md

← Older revision		Revision as of 23:49, 30 September 2026
Line 45:		Line 45:

	The <code>[[Signed-off-by]]:</code> line asserts that you have permission to contribute the code to the project according to the [[Signed-off-by\|Developer's Certificate of Origin]].		The <code>[[Signed-off-by]]:</code> line asserts that you have permission to contribute the code to the project according to the [[Signed-off-by\|Developer's Certificate of Origin]].

			Only a person can make this certification, so the <code>Signed-off-by:</code> line is that of the human submitting the patch. An AI coding agent may add it only with that person's own name and email (e.g. from their <code>git config user.name</code> and <code>user.email</code>), never with its own identity, and the person must review the patch before it is pushed. The agent is credited with an <code>Assisted-by:</code> tag instead, as described in the AI/LLM/Tool Attribution section below.

	==The Change-Id: line and Code Style==		==The Change-Id: line and Code Style==

Adilger: improve description to be consistent with AGENTS.md

2026-10-01T07:47:39Z

improve description to be consistent with AGENTS.md

← Older revision		Revision as of 23:47, 30 September 2026
Line 15:		Line 15:
	Unlike the content of the commit message, the format is relatively easy to verify for correctness. Having the same standard format allows Git tools like <code>git shortlog</code> to extract information from the patches more easily.		Unlike the content of the commit message, the format is relatively easy to verify for correctness. Having the same standard format allows Git tools like <code>git shortlog</code> to extract information from the patches more easily.

	The first line of the commit comment is the commit summary of the change. Changes submitted to the <code>fs/lustre-release</code> branch require a [https://jira.whamcloud.com/projects/LU/issues Lustre JIRA ticket] number at the beginning of the commit summary. A Lustre JIRA ticket is one that begins with LU and is therefore part of the Lustre project within JIRA. For patches to other projects, such as documentation, a different JIRA project should be used (e.g. <code>LUDOC</code>). If the patch is submitted for the <code>fs/lustre-release</code> repository without a Lustre JIRA ID in the first line, then it will automatically receive a <code>Review: -2</code> which will prevent the patch from being submitted to a release branch. You would then need to fix the summary line and resubmit the patch.		The first line of the commit comment is the commit summary of the change. Changes submitted to the <code>fs/lustre-release</code> branch require a [https://jira.whamcloud.com/projects/LU/issues Lustre JIRA ticket] number at the beginning of the commit summary. A Lustre JIRA ticket is one that begins with LU and is therefore part of the Lustre project within JIRA. For patches to other projects, such as documentation, a different JIRA project should be used (e.g. <code>LUDOC</code>). If the patch is submitted for the <code>fs/lustre-release</code> repository without a Lustre JIRA ID in the first line, then it will automatically receive a <code>Code-Review: -2</code> which will prevent the patch from being submitted to a release branch. You would then need to fix the summary line and resubmit the patch.

	The commit summary should also have a component: tag immediately following the Jira ticket number that indicates which Lustre subsystem that the commit is related to. Example Lustre subsystems relate to modules like: <code>llite</code>, <code>lov</code>, <code>osc</code>, <code>mdc</code>, <code>lmv</code>, <code>ldlm</code>, <code>ptlrpc</code>, <code>mds</code>, <code>oss</code>, <code>mdd</code>, <code>osd-ldiskfs</code>, <code>osd-zfs</code>, <code>ldiskfs</code>, <code>lnet</code>, <code>libcfs</code>, <code>socklnd</code>, <code>o2iblnd</code>; functional components like <code>recovery</code>, <code>quota</code>, <code>grant</code>, <code>nrs</code>, <code>utils</code>; or auxiliary components like <code>build</code>, <code>tests</code>, <code>iokit</code>, <code>docs</code>. This subsystem list is not exhaustive, but provides a good guideline for consistency.		The commit summary should also have a component: tag immediately following the Jira ticket number that indicates which Lustre subsystem that the commit is related to. Example Lustre subsystems relate to modules like: <code>llite</code>, <code>lov</code>, <code>osc</code>, <code>mdc</code>, <code>lmv</code>, <code>ldlm</code>, <code>ptlrpc</code>, <code>mds</code>, <code>oss</code>, <code>mdd</code>, <code>osd-ldiskfs</code>, <code>osd-zfs</code>, <code>ldiskfs</code>, <code>lnet</code>, <code>libcfs</code>, <code>socklnd</code>, <code>o2iblnd</code>; functional components like <code>recovery</code>, <code>quota</code>, <code>grant</code>, <code>nrs</code>, <code>utils</code>; or auxiliary components like <code>build</code>, <code>tests</code>, <code>iokit</code>, <code>docs</code>. This subsystem list is not exhaustive, but provides a good guideline for consistency.

	The commit summary line must be 62 characters or less, including the Jira ticket number and component tag, so that <code>git shortlog</code> and <code>git format-patch</code> can fit the summary onto a single line. The summary must be followed by a blank ~~like~~. The rest of the comments should be wrapped to 70 columns or less. This allows for the first line to be used a subject in emails, and also for the entire body to be displayed using tools like <code>git log</code> or <code>git shortlog</code> in an 80 column window.		The commit summary line must be 62 characters or less (this is enforced by the <code>commit-msg</code> hook), and should preferably be 60 characters or less, including the Jira ticket number and component tag, so that <code>git shortlog</code> and <code>git format-patch</code> can fit the summary onto a single line. The summary must be followed by a blank line. The rest of the comments should be wrapped to 70 columns or less. This allows for the first line to be used a subject in emails, and also for the entire body to be displayed using tools like <code>git log</code> or <code>git shortlog</code> in an 80 column window.

	LU-nnnnn component: short change description ~~under~~ 62 columns		LU-nnnnn component: short change description, 62 columns max

	The "component:" should be a lower-case single-word subsystem of the		The "component:" should be a lower-case single-word subsystem of the
Line 30:		Line 30:
	build, tests, docs. This list is not exhaustive, but is a guideline.		build, tests, docs. This list is not exhaustive, but is a guideline.

	The commit comment should contain a ~~detailed~~ explanation of ~~changes~~		The commit comment should contain a concise explanation of the
	being made~~. This can be as long as you'd like~~. Please give details		change being made. Please give details of what problem was solved
	of what problem was solved (including error messages or problems that		(including error messages or problems that were seen), a good
	were seen), a good high-level description of how it was solved, and		high-level description of how it was solved, and which parts of the
	which parts of the code were changed (including important functions		code were changed (including important functions that were changed,
	that were changed, if this is useful to understand the patch, and		if this is useful to understand the patch, and for easier searching).
	for easier searching). Wrap lines to fit within 70 columns.		There is no need to narrate the diff or list every small change.
			Wrap lines to fit within 70 columns.

	Signed-off-by: Your Real Name <your_email@domain.name>		Signed-off-by: Your Real Name <your_email@domain.name>