[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [PATCH] doc: identify/refer to source of each fixed bug in log,
Jim Meyering <=