Page History
Canonical version of this page is at https://wiki.lustre.org/Commit_Comments
Contents:
| Recent edits:
|
Commit message content
Writing good commit comments is critical to ensuring that changes are easily understood, even years after they were originally written. The commit comment should contain enough information about the change to allow the reader to understand the motivation for the change, what parts of the code it is affecting, and any interesting, unusual, or complex parts of the change to draw attention to.
...
For patches backported from master to a Lustre maintenance branch (e.g. b2_510) there are some conventions to follow so that the changes/fixes can more easily be tracked across branches. The best simples method for porting a patch from one branch to another is to use git cherry-pick {commit_hash} on the branch where you want the patch to land. This will apply the whole patch (as best as is able, and show conflicts where needed), copy the commit message, preserve the original patch author. With luck, there will not be any patch conflicts and no further work is needed. If necessary, the patch conflicts need to be resolved before committing the patch. For the use the "Cherry Pick" button on the patch directly in Gerrit, which can be used for patches that apply cleanly to the specified target branch as long as it is in the same Git repository. Alternately, if this is not possible, use git cherry-pick {commit_hash|branch} from the command line to pull the patch onto the (current) branch where you want the patch to land, and then using the normal patch submission process to push the patch to Gerrit or submit it to the upstream kernel. This will apply the whole patch (as best as is able, and show conflicts where needed), copy the commit message, preserve the original patch author. With luck, there will not be any patch conflicts and no further work is needed. If necessary, the patch conflicts need to be resolved before committing the patch. For the commit message:
:
Patches ported from master to maintenance branch
For example, porting a patch from master to b2_10 or similar:
| No Format |
|---|
LU |
| No Format |
LU-4725 mdt: child-parent lock ordering in rename
Change rename so that it always has parent-child lock ordering,
otherwise it may deadlock with other operations.
Lustre-commit: 4e308ef74f271ec7e19917e3c0f88586537582c3
Lustre-change: http://review.whamcloud.com/9538
LU-4725 obd: lu_object_find_at hung
lu_object_find_at hangs if called two times and object is removed
in between. It makes mdt_rename_sanity not workable for rename.
Change mdt_rename_sanity to work on existing object.
Lustre-commit: b7c72ec1ddeda2cf94ea151f974d3f94e3a7d1ed
Lustre-change: http://review.whamcloud.com/10484
Xyratex-bug-id: MRP-1700
Test-Parameters: alwaysuploadlogs \
envdefinitions=SLOW=yes,ENABLE_QUOTA=yes,ONLY=54 \
ossjob=lustre-b2_4 mdsjob=lustre-b2_4 ossbuildno=73 mdsbuildno=73 \
testlist=sanityn
Signed-off-by: Vitaly Fertman <vitaly_fertman@xyratex.com>
Signed-off-by: Rahul Deshmukh <rahul_deshmukh@xyratex.com>
Change-Id: Ic9ce52bfcd8788834347fba155cc8c6be674dcd8 |
...
Patches ported from master to
...
upstream kernel
These are treated similarly as patches ported to maintenance branches (keep all comments and Signed-off-by: lines from the original patch) add new Signed-off-by: and comments afterward, but replace the Lustre-commit: line (which doesn't mean anything in the upstream kernel git) with Intel-bug-id: {jira_URL} so that the original bug can still be identified:Intel-bug-id: {jira_URL} so that the original bug can still be identified. When submitting patches upstream, please also follow the Documentation/process/submitting-patches.rst instructions, and use scripts/get_maintainer.pl to generate the CC list for the patch. If in doubt, submit the patch only to lustre-devel first to get feedback from the Lustre maintainers.
| No Format |
|---|
lustre/llite: simplify dentry revalidate
Lustre client dentry validation is protected by LDLM lock, so
any time a dentry is found, it's valid and no need to revalidate
from MDS, and even it does, there is race that it may be
invalidated after revalidation is finished.
Signed-off-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-on: http://review.whamcloud.com/7475
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3544
Signed-off-by: Lai Siyao <lai.siyao@intel.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
|
...
Overview
Content Tools
Authorof the patch should be kept. This should be done automatically when usinggit cherry-pickbut is lost when applying the patch manually, sogit commit --author="Original Author <author@email.com>"should be usedSigned-off-by:line of the original author should also be keptSigned-off-by:line with their name and email following the original oneChange-Id:lineReviewed-by:lines can be kept, and Gerrit will automatically add them as reviewers to the new patchTested-by: MalooandTested-by: Jenkinslines should be removed from the new commit message, though anyTested-by:lines from real people can be kept"Reviewed-on: http://review.whamcloud.com/nnnnn"line should be changed to"Lustre-change: http://review.whamcloud.com/nnnnn"(please use the "permalink" Gerrit URL format as shown)"cherry picked from commit abcdef1234567890"line should be changed to"Lustre-commit: abcdef1234567890"Signed-off-by:andLustre-commit:lines before your ownSigned-off-by:lineSigned-off-by:andLustre-commit:andLustre-change:lines of each commit