diff options
| author | Jim Meyering <meyering@redhat.com> | 2012-04-03 16:14:32 +0200 |
|---|---|---|
| committer | Jim Meyering <meyering@redhat.com> | 2012-04-03 16:14:32 +0200 |
| commit | 5e1f5c5739766f054e773e296570ec410377ec25 (patch) | |
| tree | 68a9a608adc126fe9a0c2e1f0729a10360a430b6 | |
| parent | 0f35329876580f07daa30534ce924237f1357539 (diff) | |
| download | coreutils-5e1f5c5739766f054e773e296570ec410377ec25.tar.xz | |
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.
| -rw-r--r-- | HACKING | 11 |
1 files changed, 11 insertions, 0 deletions
@@ -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 ============================= |