Lines Matching +full:commit +full:- +full:message

18 than re-writing them in a saner format. Any change you make, please
21 Commit format
24 Each commit should do one thing, and one thing only. If you find yourself,
25 in the commit message, adding phrases like "Also do [...]" or "While in
29 commit, done first. That means this preparatory commit won't have any
30 functional changes, and hence should be a no-op. It also means that your
31 main commit, with the change that you actually care about, will be smaller
34 Each commit must stand on its own in terms of what it provides, and how it
35 works. Lots of changes are just a single commit, but for something a bit
37 commits. Make each commit as simple as possible, and not any simpler. We'd
40 change, then please make that change as a separate commit, explaining why
43 Each commit in a series must be buildable, it's not enough that the end
48 out in the commit, and the author then does a followup fix for that
50 commit that introduced the problem in the first place. This is done by
51 amending the fix into the original commit that caused the issue. You can
52 do that with git rebase -i <sha> and arrange the commit order such that
53 the fixup is right after the original commit, and then use 's' (for
54 squash) to squash the fixup into the original commit. Don't forget to
55 edit the commit message while doing that, as git will combine the two
56 commit messages into one. Or you can do it manually. Once done, force
57 push your rewritten git history. See reasons 1-3 in the introduction
60 Commit message
63 A good commit explains the WHY of a commit - explain the reason for this
64 commit to exist. Don't explain what the code in commit does, that should
67 explanation in the commit message. liburing commits use the following
72 Body of commit
74 Signed-off-by: ```My Identity <my@email.com>```
77 the body of the commit message, then an empty line, and finally an SOB
78 tag. The signed-off-by exists to provide proof of origin, see the
81 Example commit:
84 commit 0fe5c09195c0918f89582dd6ff098a58a0bdf62a
86 Date:   Fri Sep 6 15:54:04 2024 -0600
90     The previous commit is mixing private structures and defines with public
95     Signed-off-by: Jens Axboe <axboe@kernel.dk>
102 A Fixes line can be added if this commit fixes an issue in a previous
103 commit. That kind of meta data can be useful down the line for finding
112 formatted Fixes line for the commit. Likewise, other meta data can be:
117 commit, perhaps a bug report. This can be a GitHub issue as well. If a
118 commit closes/solves a GitHub issue, than:
124 Each commit message should be formatted so each full line is 72-74 chars
126 often used in a terminal to browse the repo. Breaking lines at 72-74
134 however please ensure that this doesn't come at the expense of the commit
135 messages themselves being lacking. The commit messages should stand on
137 message. If you've worked on projects that send patches before, consider
138 the PR message similar to the cover letter for a series of patches.
142 mailing list: io-uring@vger.kernel.org.
144 liburing doesn't squash/rebase-on-merge, or other heinous practices
145 sometimes seen elsewhere. Whatever sha your commit has in your tree is
147 pull requests are merged with a merge commit. If meta data needs to go
148 into the merge commit, then it will go into the merge commit message.