From 42b2f1f8b853a6b68af8c44a8e42a698ff3ef236 Mon Sep 17 00:00:00 2001 From: Michal Privoznik Date: Mon, 24 Oct 2022 13:45:23 +0200 Subject: [PATCH] docs: Update best practices wrt "Fixes:" and GitLab We document that a commit fixing an issue tracked in GitLab should put just "Fixes: #NNN" into its commit message. But when viewing git log, having full URL which is directly clickable is more developer friendly and GitLab is capable of handling both. Therefore, document that users should put full URL, just like when fixing a bug tracked in other sites. Signed-off-by: Michal Privoznik Reviewed-by: Peter Krempa --- docs/best-practices.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/best-practices.rst b/docs/best-practices.rst index ba8478ab05..1e5817f714 100644 --- a/docs/best-practices.rst +++ b/docs/best-practices.rst @@ -14,12 +14,12 @@ with minimal back-and-forth. (60 characters is typical), followed by a blank line, followed by any longer description of why your patch makes sense. If the patch fixes a regression, and you know what commit introduced - the problem, mentioning that is useful. If the patch resolves a - upstream bug reported in GitLab, put "Fixes: #NNN" in the commit - message. For a downstream bug, mention the URL of the bug instead. - In both cases also summarize the issue rather than making all - readers follow the link. You can use 'git shortlog -30' to get - an idea of typical summary lines. + the problem, mentioning that is useful. If the patch resolves + an upstream bug reported in GitLab, or downstream bug, put + "Resolves: $fullURL" of the bug. In both cases also summarize + the issue rather than making all readers follow the link. You + can use 'git shortlog -30' to get an idea of typical summary + lines. - Split large changes into a series of smaller patches, self-contained if possible, with an explanation of each patch