SHOW:
|
|
- or go back to the newest paste.
| 1 | Linus Torvalds's commit message style guide. | |
| 2 | - | Taken from the README for one of this projects[0]. |
| 2 | + | Taken from the README for one of his projects[0]. |
| 3 | ||
| 4 | For examples of commit messages in this style, see `git log` for the linux | |
| 5 | kernel[1] project. | |
| 6 | ||
| 7 | =============================================================================== | |
| 8 | Also, please write good git commit messages. A good commit message | |
| 9 | looks like this: | |
| 10 | ||
| 11 | Header line: explaining the commit in one line | |
| 12 | ||
| 13 | Body of commit message is a few lines of text, explaining things | |
| 14 | in more detail, possibly giving some background about the issue | |
| 15 | being fixed, etc etc. | |
| 16 | ||
| 17 | The body of the commit message can be several paragraphs, and | |
| 18 | please do proper word-wrap and keep columns shorter than about | |
| 19 | 74 characters or so. That way "git log" will show things | |
| 20 | nicely even when it's indented. | |
| 21 | ||
| 22 | Reported-by: whoever-reported-it | |
| 23 | Signed-off-by: Your Name <[email protected]> | |
| 24 | ||
| 25 | where that header line really should be meaningful, and really should be | |
| 26 | just one line. That header line is what is shown by tools like gitk and | |
| 27 | shortlog, and should summarize the change in one readable line of text, | |
| 28 | independently of the longer explanation. | |
| 29 | =============================================================================== | |
| 30 | ||
| 31 | 0: https://github.com/torvalds/subsurface | |
| 32 | 1: https://github.com/torvalds/linux/commits/master |
