Commit Comments - Revision history

Adilger: /* Additional commit tags */ add AI attribution policy, update optional tags

2026-05-16T05:42:35Z

Additional commit tags: add AI attribution policy, update optional tags

← Older revision		Revision as of 22:42, 15 May 2026
Line 91:		Line 91:
	; <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-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-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-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

			==AI/LLM/Tool Attribution==

			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 in the following format:

			Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

			Where:
			* <code>AGENT_NAME</code> is the name of the AI tool or framework
			* <code>MODEL_VERSION</code> is the specific model version used
			* <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>)
			Basic development tools (<code>git</code>, <code>gcc</code>, <code>make</code>, <code>editors</code>) should not be listed.



	==Additional commit tags==		==Additional commit tags==
Line 97:		Line 111:

	Acked-by: User Name <user@domain.com>		Acked-by: User Name <user@domain.com>
	Tested-by: User ~~Name~~ <~~user~~@domain.com>		Tested-by: Diligent User <diligent@domain.com>
	Reported-by: User ~~Name~~ <~~user~~@domain.com>		Reported-by: Inquisitive User <inquisitive@domain.com>
	Reviewed-by: User ~~Name~~ <~~user~~@domain.com>		Reviewed-by: Dedicated User <dedicated@domain.com>
			Suggested-by: Inventive User <inventive@domain.com>
	Test-Parameters: additional testing parameters		Test-Parameters: additional testing parameters
	CC: User ~~Name~~ <~~user~~@domain.com>		CC: Observant User <observant@domain.com>
	CoverityID: nnnnnn ("type of issue")		CoverityID: nnnnnn ("type of issue")
	{Organization}-bug-id: arbitrary bug tracking identifier		{Organization}-bug-id: arbitrary bug tracking identifier

Adilger: /* Additional commit tags */ add separate sections for Fixes: and Test-Parameters:

2026-02-24T22:55:18Z

Additional commit tags: add separate sections for Fixes: and Test-Parameters:

@@ Line 59: / Line 59: @@
 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.
 ==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 Signed-off-by: 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.
      Acked-by: User Name <user@domain.com>
      Tested-by: User Name <user@domain.com>
@@ Line 76: / Line 107: @@
      Lustre-commit: {git commit hash of master patch}
      Linux-commit: {git commit hash of upstream kernel patch}
 The <code>{Organization}-bug-id:</code> tag (e.g. <code>Whamcloud-bug-id: LDEV-123</code>, <code>HPE-bug-id: MRP-123</code>, or <code>Oracle-bug-id: b=12345</code>) can be used to track this patch in other bug databases.
@@ Line 93: / Line 115: @@
 Patches ported from the upstream kernel, the patch should keep the original commit summary line, with slight modification to conform to Lustre standards: include the JIRA LU ticket number, and replace "staging" and other pathnames in the summary with a subsystem. The <code>Linux-commit:</code> tag is used to reference the upstream kernel commit hash when it is merged into the master branch.  The original author should be kept as the author of the patch using the <code>git --author</code> option, as well as the original <code>Signed-off-by:</code> tag(s).
 ==Examples of good commit comments==

Adilger: /* Patches ported from master to upstream kernel */ restore intel emails, but add Change-Id

2026-02-24T22:30:49Z

Patches ported from master to upstream kernel: restore intel emails, but add Change-Id

← Older revision		Revision as of 15:30, 24 February 2026
Line 243:		Line 243:
	Reviewed-on: http://review.whamcloud.com/7475		Reviewed-on: http://review.whamcloud.com/7475
	Lustre-bug-id: https://jira.whamcloud.com/browse/LU-3544		Lustre-bug-id: https://jira.whamcloud.com/browse/LU-3544
	Signed-off-by: Lai Siyao <lai.siyao@~~whamcloud~~.com>		Change-Id: I7700cbaddc4ec08e12c9f7d8021783a6135dd35a
	Signed-off-by: Oleg Drokin <~~green~~@~~whamcloud~~.com>		Signed-off-by: Lai Siyao <lai.siyao@intel.com>
			Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>

	[[Category:Development]]		[[Category:Development]]

Adilger: /* Patches ported from master to upstream kernel */ remove old intel emails

2026-02-24T22:29:24Z

Patches ported from master to upstream kernel: remove old intel emails

← Older revision		Revision as of 15:29, 24 February 2026
Line 232:		Line 232:
	==Patches ported from master to upstream kernel==		==Patches ported from master to upstream kernel==

	These are treated similarly as patches ported to maintenance branches (keep all comments and <code>[[Signed-off-by]]:</code> lines from the original patch) add new <code>Signed-off-by:</code> and comments afterward, but replace the <code>Lustre-commit:</code> line (which doesn't mean anything in the upstream kernel git) with <code>~~Intel~~-bug-id:</code> (or equivalent internal tracking information {jira_URL} so that the original bug can still be identified. When submitting patches upstream, please also follow the <code>Documentation/process/submitting-patches.rst</code> instructions in the kernel tree, and use <code>contrib/scripts/get_maintainer.pl</code> to generate the CC list for the patch. If in doubt, submit the patch only to <code>lustre-devel</code> first to get feedback from the Lustre maintainers.		These are treated similarly as patches ported to maintenance branches (keep all comments and <code>[[Signed-off-by]]:</code> lines from the original patch) add new <code>Signed-off-by:</code> and comments afterward, but replace the <code>Lustre-commit:</code> line (which doesn't mean anything in the upstream kernel git) with <code>Lustre-bug-id:</code> (or equivalent internal tracking information {jira_URL} so that the original bug can still be identified. When submitting patches upstream, please also follow the <code>Documentation/process/submitting-patches.rst</code> instructions in the kernel tree, and use <code>contrib/scripts/get_maintainer.pl</code> to generate the CC list for the patch. If in doubt, submit the patch only to <code>lustre-devel</code> first to get feedback from the Lustre maintainers.

	lustre/llite: simplify dentry revalidate		lustre/llite: simplify dentry revalidate
Line 242:		Line 242:

	Reviewed-on: http://review.whamcloud.com/7475		Reviewed-on: http://review.whamcloud.com/7475
	~~Intel~~-bug-id: https://jira.~~hpdd.intel~~.com/browse/LU-3544		Lustre-bug-id: https://jira.whamcloud.com/browse/LU-3544
	Signed-off-by: Lai Siyao <lai.siyao@~~intel~~.com>		Signed-off-by: Lai Siyao <lai.siyao@whamcloud.com>
	Signed-off-by: Oleg Drokin <~~oleg.drokin~~@~~intel~~.com>		Signed-off-by: Oleg Drokin <green@whamcloud.com>

	[[Category:Development]]		[[Category:Development]]

Adilger: /* The Change-Id: line and Code Style */ add "Was-Change-Id:" description

2025-01-14T22:53:43Z

The Change-Id: line and Code Style: add "Was-Change-Id:" description

← Older revision		Revision as of 15:53, 14 January 2025
Line 57:		Line 57:

	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/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.

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

Adilger: /* Additional commit tags */ add pretty=fixes description

2024-12-12T23:01:18Z

Additional commit tags: add pretty=fixes description

← Older revision		Revision as of 16:01, 12 December 2024
Line 75:		Line 75:
	Linux-commit: {git commit hash of upstream kernel patch}		Linux-commit: {git commit hash of upstream kernel patch}

	The <code>Fixes:</code> tag is useful for tracking a fix made to a previous commit, in case the earlier patch is being cherry-picked for a different branch, it is easier to find any later patches that fix it.		The <code>Fixes:</code> tag is useful for tracking a fix made to a previous commit, in case the earlier patch is being cherry-picked for a different branch, it is easier to find any later patches that fix it. This line can be generated with the following lines in your <code>.gitconfig</code> file:

			[pretty]
			fixes=Fixes: %h (\"%s\")

			and then running:

			$ git log -1 --pretty=fixes commit_hash

	The <code>{Organization}-bug-id:</code> tag (e.g. <code>Whamcloud-bug-id: LDEV-123</code>, <code>HPE-bug-id: MRP-123</code>, or <code>Oracle-bug-id: b=12345</code>) can be used to track this patch in other bug databases.		The <code>{Organization}-bug-id:</code> tag (e.g. <code>Whamcloud-bug-id: LDEV-123</code>, <code>HPE-bug-id: MRP-123</code>, or <code>Oracle-bug-id: b=12345</code>) can be used to track this patch in other bug databases.

Adilger: /* Additional commit tags */

2024-01-23T22:52:44Z

Additional commit tags

← Older revision		Revision as of 15:52, 23 January 2024
Line 71:		Line 71:
	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-~~nnnn~~		Lustre-change: https://jira.whamcloud.com/browse/LU-nnnnn
	Lustre-commit: {git commit hash of master patch}		Lustre-commit: {git commit hash of master patch}
	Linux-commit: {git commit hash of upstream kernel patch}		Linux-commit: {git commit hash of upstream kernel patch}

Adilger: /* Additional commit tags */ add Coverity ID

2024-01-23T22:52:29Z

Additional commit tags: add Coverity ID

← Older revision		Revision as of 15:52, 23 January 2024
Line 69:		Line 69:
	Test-Parameters: additional testing parameters		Test-Parameters: additional testing parameters
	CC: User Name <user@domain.com>		CC: User Name <user@domain.com>
			CoverityID: nnnnnn ("type of issue")
	{Organization}-bug-id: arbitrary bug tracking identifier		{Organization}-bug-id: arbitrary bug tracking identifier
	Lustre-~~commit~~: ~~{git commit hash of original patch}~~		Lustre-change: https://jira.whamcloud.com/browse/LU-nnnn
	Lustre-~~change~~: {~~Gerrit change URL~~ of ~~original~~ patch}		Lustre-commit: {git commit hash of master patch}
	Linux-commit: {git commit hash of upstream kernel patch}		Linux-commit: {git commit hash of upstream kernel patch}

Line 80:		Line 81:
	The <code>Lustre-commit:</code> and <code>Lustre-change:</code> tags are used to reference the original <code>master</code> version of a patch that is being ported to another branch.		The <code>Lustre-commit:</code> and <code>Lustre-change:</code> tags are used to reference the original <code>master</code> version of a patch that is being ported to another branch.

	Patches pushed to the upstream kernel should include <code>Lustre-bug-id:</code> to reference the JIRA URL for the LU ticket, in the form <code>https://jira.whamcloud.com/browse/LU-~~nnnn~~</code>. Patches should also include the <code>Reviewed-on:</code> permalink URL for the Gerrit patch, in the form <code>https://review.whamcloud.com/nnnnn</code>. The upstream maintainers do not want to have commit hashes for non-kernel commits, so upstream patches should not include the <code>Lustre-commit:</code> tag.		Patches pushed to the upstream kernel should include <code>Lustre-bug-id:</code> to reference the JIRA URL for the LU ticket, in the form <code>https://jira.whamcloud.com/browse/LU-nnnnn</code>. Patches should also include the <code>Reviewed-on:</code> permalink URL for the Gerrit patch, in the form <code>https://review.whamcloud.com/nnnnn</code>. The upstream maintainers do not want to have commit hashes for non-kernel commits, so upstream patches should not include the <code>Lustre-commit:</code> tag.

	Patches ported from the upstream kernel, the patch should keep the original commit summary line, with slight modification to conform to Lustre standards: include the JIRA LU ticket number, and replace "staging" and other pathnames in the summary with a subsystem. The <code>Linux-commit:</code> tag is used to reference the upstream kernel commit hash when it is merged into the master branch. The original author should be kept as the author of the patch using the <code>git --author</code> option, as well as the original <code>Signed-off-by:</code> tag(s).		Patches ported from the upstream kernel, the patch should keep the original commit summary line, with slight modification to conform to Lustre standards: include the JIRA LU ticket number, and replace "staging" and other pathnames in the summary with a subsystem. The <code>Linux-commit:</code> tag is used to reference the upstream kernel commit hash when it is merged into the master branch. The original author should be kept as the author of the patch using the <code>git --author</code> option, as well as the original <code>Signed-off-by:</code> tag(s).

Adilger: /* Additional commit tags */ replace Xyratex with HPE

2024-01-23T22:49:50Z

Additional commit tags: replace Xyratex with HPE

← Older revision		Revision as of 15:49, 23 January 2024
Line 76:		Line 76:
	The <code>Fixes:</code> tag is useful for tracking a fix made to a previous commit, in case the earlier patch is being cherry-picked for a different branch, it is easier to find any later patches that fix it.		The <code>Fixes:</code> tag is useful for tracking a fix made to a previous commit, in case the earlier patch is being cherry-picked for a different branch, it is easier to find any later patches that fix it.

	The <code>{Organization}-bug-id:</code> tag (e.g. <code>Whamcloud-bug-id: LDEV-123</code>, <code>~~Xyratex~~-bug-id: MRP-123</code>, or <code>Oracle-bug-id: b=12345</code>) can be used to track this patch in other bug databases.		The <code>{Organization}-bug-id:</code> tag (e.g. <code>Whamcloud-bug-id: LDEV-123</code>, <code>HPE-bug-id: MRP-123</code>, or <code>Oracle-bug-id: b=12345</code>) can be used to track this patch in other bug databases.

	The <code>Lustre-commit:</code> and <code>Lustre-change:</code> tags are used to reference the original <code>master</code> version of a patch that is being ported to another branch.		The <code>Lustre-commit:</code> and <code>Lustre-change:</code> tags are used to reference the original <code>master</code> version of a patch that is being ported to another branch.

Adilger: /* The Change-Id: line and Code Style */

2022-06-17T05:53:15Z

The Change-Id: line and Code Style

← Older revision		Revision as of 22:53, 16 June 2022
Line 56:		Line 56:
	$ 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.		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.

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