diff options
Diffstat (limited to 'Documentation/MyFirstContribution.txt')
| -rw-r--r-- | Documentation/MyFirstContribution.txt | 23 |
1 files changed, 19 insertions, 4 deletions
diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt index 4f85a08..7c9a037 100644 --- a/Documentation/MyFirstContribution.txt +++ b/Documentation/MyFirstContribution.txt @@ -249,7 +249,7 @@ component you're working on, followed by a blank line (always required) and then the body of your commit message, which should provide the bulk of the context. Remember to be explicit and provide the "Why" of your change, especially if it couldn't easily be understood from your diff. When editing your commit message, -don't remove the Signed-off-by line which was added by `-s` above. +don't remove the `Signed-off-by` trailer which was added by `-s` above. ---- psuh: add a built-in by popular demand @@ -507,6 +507,9 @@ documentation is consistent with other Git and UNIX manpages; this makes life easier for your user, who can skip to the section they know contains the information they need. +NOTE: Before trying to build the docs, make sure you have the package `asciidoc` +installed. + Now that you've written your manpage, you'll need to build it explicitly. We convert your AsciiDoc to troff which is man-readable like so: @@ -522,8 +525,6 @@ $ make -C Documentation/ git-psuh.1 $ man Documentation/git-psuh.1 ---- -NOTE: You may need to install the package `asciidoc` to get this to work. - While this isn't as satisfying as running through `git help`, you can at least check that your help page looks right. @@ -1142,11 +1143,25 @@ After a few days, you will hopefully receive a reply to your patchset with some comments. Woohoo! Now you can get back to work. It's good manners to reply to each comment, notifying the reviewer that you have -made the change requested, feel the original is better, or that the comment +made the change suggested, feel the original is better, or that the comment inspired you to do something a new way which is superior to both the original and the suggested change. This way reviewers don't need to inspect your v2 to figure out whether you implemented their comment or not. +Reviewers may ask you about what you wrote in the patchset, either in +the proposed commit log message or in the changes themselves. You +should answer these questions in your response messages, but often the +reason why reviewers asked these questions to understand what you meant +to write is because your patchset needed clarification to be understood. + +Do not be satisfied by just answering their questions in your response +and hear them say that they now understand what you wanted to say. +Update your patches to clarify the points reviewers had trouble with, +and prepare your v2; the words you used to explain your v1 to answer +reviewers' questions may be useful thing to use. Your goal is to make +your v2 clear enough so that it becomes unnecessary for you to give the +same explanation to the next person who reads it. + If you are going to push back on a comment, be polite and explain why you feel your original is better; be prepared that the reviewer may still disagree with you, and the rest of the community may weigh in on one side or the other. As |