Junio C Hamano <gitster@xxxxxxxxx> writes:
> Jason Holden <jason.k.holden.swdev@xxxxxxxxx> writes:
>
>> Any reason to leave out the maintainers email addresses?
>
> Nothing particular, other than that I did not find anywhere in the
> file that does not break the flow.
I've prepared this on top of the previous three. The second hunk
that updates "(4) Sending your patches." is the logical place to
have this information.
The other hunks are correcting minor mistakes that are not related.
I think I'll squash them to the patch 3/3.
Documentation/SubmittingPatches | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index a7daad3..9e113d0 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -31,8 +31,9 @@ change is relevant to.
these parts should be based on their trees.
To find the tip of a topic branch, run "git log --first-parent
-master..pu" and look for the merge commit. The second parent of this
-commit is the tip of the topic branch.
+master..pu" and look for merge commits. The second parent of these
+commits are the tips of topic branches.
+
(1) Make separate commits for logically separate changes.
@@ -70,6 +71,7 @@ changes do not trigger errors with the sample pre-commit hook shipped
in templates/hooks--pre-commit. To help ensure this does not happen,
run git diff --check on your changes before you commit.
+
(2) Describe your changes well.
The first line of the commit message should be a short description (50
@@ -185,14 +187,20 @@ not a text/plain, it's something else.
Send your patch with "To:" set to the mailing list, with "cc:" listing
people who are involved in the area you are touching (the output from
"git blame $path" and "git shortlog --no-merges $path" would help to
-identify them), to solicit comments and reviews. After the list
-reached a consensus that it is a good idea to apply the patch, re-send
-it with "To:" set to the maintainer and "cc:" the list for inclusion.
-Do not forget to add trailers such as "Acked-by:", "Reviewed-by:" and
-"Tested-by:" after your "Signed-off-by:" line as necessary.
+identify them), to solicit comments and reviews.
+
+After the list reached a consensus that it is a good idea to apply the
+patch, re-send it with "To:" set to the maintainer [*1*] and "cc:" the
+list [*2*] for inclusion. Do not forget to add trailers such as
+"Acked-by:", "Reviewed-by:" and "Tested-by:" after your
+"Signed-off-by:" line as necessary.
+
+ [Addresses]
+ *1* The current maintainer: gitster@xxxxxxxxx
+ *2* The mailing list: git@xxxxxxxxxxxxxxx
-(4) Sign your work
+(5) Sign your work
To improve tracking of who did what, we've borrowed the
"sign-off" procedure from the Linux kernel project on patches
@@ -304,7 +312,8 @@ suggests to the contributors:
even get them in a "on top of your change" patch form.
(3) Polish, refine, and re-send to the list and the people who
- spend their time to improve your patch. Go back to step (2).
+ spent their time to help improving your patch. Go back to
+ step (2) until step (4) happens.
(4) The list forms consensus that the last round of your patch is
good. Send it to the list and cc the maintainer.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html