coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] doc: identify/refer to source of each fixed bug in log


From: Jim Meyering
Subject: [PATCH] doc: identify/refer to source of each fixed bug in log
Date: Tue, 03 Apr 2012 19:51:05 +0200

Just codifying existing practice...

>From 5e1f5c5739766f054e773e296570ec410377ec25 Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Tue, 3 Apr 2012 16:14:32 +0200
Subject: [PATCH] doc: identify/refer to source of each fixed bug in log
 and in NEWS

* HACKING (Commit log requirements): Describe our policy: when you
fix a bug, put the "git describe" string of the bug-introducing commit
in your commit log and put the "fixed-in-release version number"
in the NEWS blurb.
---
 HACKING |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/HACKING b/HACKING
index b05fd54..f8d3a9b 100644
--- a/HACKING
+++ b/HACKING
@@ -232,6 +232,17 @@ Try to make the summary line fit one of the following 
forms:
   build: change-description
   maint: change-description

+If your commit fixes a bug, try to find the commit that introduced that
+bug.  If you do that, add a note in your new commit log saying something
+like "Introduced by commit v8.12-103-g54cbe6e." and add something like
+[bug introduced in coreutils-8.13] in the corresponding NEWS blurb.
+Assuming you found the bug in commit 54cbe6e6, "git describe 54cbe6e6"
+will print the longer tag-relative string that you'll need.
+Note that we used to use an 8-byte SHA1 prefix like "54cbe6e6", because
+that was automatically rendered as a clickable link by "gitk", but with
+git-1.7.10, the more descriptive version-containing "git describe" format
+that we now require is also highlighted.
+

 Curly braces: use judiciously
 =============================
--
1.7.9.3



reply via email to

[Prev in Thread] Current Thread [Next in Thread]