From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: [PATCH v2 1/2] SubmittingPatches: move the patch-flow section earlier
Date: Fri, 10 May 2024 09:55:25 -0700 [thread overview]
Message-ID: <20240510165526.1412338-2-gitster@pobox.com> (raw)
In-Reply-To: <20240510165526.1412338-1-gitster@pobox.com>
Before discussing the small details of how the patch gets sent, we'd
want to give people a larger picture first to set the expectation
straight. The existing patch-flow section covers materials that are
suitable for that purpose, so move it to the beginning of the
document. We'll update the contents of the section to clarify what
goal the patch submitter is working towards in the next step, which
will make it easier to understand the reason behind the individual
rules presented in latter parts of the document.
This step only moves two sections (patch-flow and patch-status)
without changing their contents, except that their section levels
are demoted from Level 1 to Level 2 to fit better in the document
structure at their new place.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/SubmittingPatches | 98 ++++++++++++++++-----------------
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 384893be1c..e82c119dfa 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -7,6 +7,55 @@ Here are some guidelines for contributing back to this
project. There is also a link:MyFirstContribution.html[step-by-step tutorial]
available which covers many of these same guidelines.
+[[patch-flow]]
+=== An ideal patch flow
+
+Here is an ideal patch flow for this project the current maintainer
+suggests to the contributors:
+
+. You come up with an itch. You code it up.
+
+. Send it to the list and cc people who may need to know about
+ the change.
++
+The people who may need to know are the ones whose code you
+are butchering. These people happen to be the ones who are
+most likely to be knowledgeable enough to help you, but
+they have no obligation to help you (i.e. you ask for help,
+don't demand). +git log -p {litdd} _$area_you_are_modifying_+ would
+help you find out who they are.
+
+. You get comments and suggestions for improvements. You may
+ even get them in an "on top of your change" patch form.
+
+. Polish, refine, and re-send to the list and the people who
+ spend their time to improve your patch. Go back to step (2).
+
+. The list forms consensus that the last round of your patch is
+ good. Send it to the maintainer and cc the list.
+
+. A topic branch is created with the patch and is merged to `next`,
+ and cooked further and eventually graduates to `master`.
+
+In any time between the (2)-(3) cycle, the maintainer may pick it up
+from the list and queue it to `seen`, in order to make it easier for
+people to play with it without having to pick up and apply the patch to
+their trees themselves.
+
+[[patch-status]]
+=== Know the status of your patch after submission
+
+* You can use Git itself to find out when your patch is merged in
+ master. `git pull --rebase` will automatically skip already-applied
+ patches, and will let you know. This works only if you rebase on top
+ of the branch in which your patch has been merged (i.e. it will not
+ tell you if your patch is merged in `seen` if you rebase on top of
+ master).
+
+* Read the Git mailing list, the maintainer regularly posts messages
+ entitled "What's cooking in git.git" giving
+ the status of various proposed changes.
+
[[choose-starting-point]]
=== Choose a starting point.
@@ -562,55 +611,6 @@ repositories.
Patches to these parts should be based on their trees.
-[[patch-flow]]
-== An ideal patch flow
-
-Here is an ideal patch flow for this project the current maintainer
-suggests to the contributors:
-
-. You come up with an itch. You code it up.
-
-. Send it to the list and cc people who may need to know about
- the change.
-+
-The people who may need to know are the ones whose code you
-are butchering. These people happen to be the ones who are
-most likely to be knowledgeable enough to help you, but
-they have no obligation to help you (i.e. you ask for help,
-don't demand). +git log -p {litdd} _$area_you_are_modifying_+ would
-help you find out who they are.
-
-. You get comments and suggestions for improvements. You may
- even get them in an "on top of your change" patch form.
-
-. Polish, refine, and re-send to the list and the people who
- spend their time to improve your patch. Go back to step (2).
-
-. The list forms consensus that the last round of your patch is
- good. Send it to the maintainer and cc the list.
-
-. A topic branch is created with the patch and is merged to `next`,
- and cooked further and eventually graduates to `master`.
-
-In any time between the (2)-(3) cycle, the maintainer may pick it up
-from the list and queue it to `seen`, in order to make it easier for
-people to play with it without having to pick up and apply the patch to
-their trees themselves.
-
-[[patch-status]]
-== Know the status of your patch after submission
-
-* You can use Git itself to find out when your patch is merged in
- master. `git pull --rebase` will automatically skip already-applied
- patches, and will let you know. This works only if you rebase on top
- of the branch in which your patch has been merged (i.e. it will not
- tell you if your patch is merged in `seen` if you rebase on top of
- master).
-
-* Read the Git mailing list, the maintainer regularly posts messages
- entitled "What's cooking in git.git" giving
- the status of various proposed changes.
-
== GitHub CI[[GHCI]]
With an account at GitHub, you can use GitHub CI to test your changes
--
2.45.0-119-g0f3415f1f8
next prev parent reply other threads:[~2024-05-10 16:55 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-15 23:20 [RFC PATCH] doc: describe the project's decision-making process Josh Steadmon
2024-04-16 0:24 ` Junio C Hamano
2024-04-22 21:10 ` Josh Steadmon
2024-04-22 21:30 ` Junio C Hamano
2024-04-23 22:41 ` Junio C Hamano
2024-04-17 16:32 ` Enrico Mrass
2024-04-17 16:58 ` Junio C Hamano
2024-05-03 14:45 ` Junio C Hamano
2024-05-03 15:48 ` Josh Steadmon
2024-05-03 18:08 ` Junio C Hamano
2024-05-03 19:29 ` Taylor Blau
2024-05-06 7:12 ` Patrick Steinhardt
2024-05-06 20:14 ` Taylor Blau
2024-05-06 19:36 ` Josh Steadmon
2024-05-06 20:17 ` Taylor Blau
2024-04-22 18:41 ` Emily Shaffer
2024-04-22 19:18 ` Junio C Hamano
2024-04-22 21:12 ` Emily Shaffer
2024-04-23 1:10 ` Junio C Hamano
2024-05-09 0:01 ` [PATCH v2] " Josh Steadmon
2024-05-09 18:10 ` Junio C Hamano
2024-05-09 19:20 ` Junio C Hamano
2024-05-09 21:13 ` [PATCH 0/2] Describe patch-flow better in SubmittingPatches Junio C Hamano
2024-05-09 21:13 ` [PATCH 1/2] SubmittingPatches: move the patch-flow section earlier Junio C Hamano
2024-05-09 21:13 ` [PATCH 2/2] SubmittingPatches: extend the "flow" section Junio C Hamano
2024-05-10 10:08 ` Karthik Nayak
2024-05-10 15:59 ` Junio C Hamano
2024-05-10 19:09 ` Karthik Nayak
2024-05-10 16:55 ` [PATCH v2 0/2] Describe life cycle of a patch series Junio C Hamano
2024-05-10 16:55 ` Junio C Hamano [this message]
2024-05-10 16:55 ` [PATCH v2 2/2] SubmittingPatches: extend the "flow" section Junio C Hamano
2024-05-10 16:56 ` [PATCH] decisions: focus on larger scale issues Junio C Hamano
2024-05-15 20:36 ` Josh Steadmon
2024-05-15 20:50 ` Junio C Hamano
2024-05-15 20:35 ` [PATCH v2 0/2] Describe life cycle of a patch series Josh Steadmon
2024-05-16 21:20 ` [PATCH v3] doc: describe the project's decision-making process Josh Steadmon
2024-05-16 22:01 ` Junio C Hamano
2024-05-17 20:18 ` Josh Steadmon
2024-05-17 6:29 ` Patrick Steinhardt
2024-05-17 16:40 ` Junio C Hamano
2024-05-21 5:56 ` Patrick Steinhardt
2024-05-17 20:35 ` [PATCH v4] " Josh Steadmon
2024-05-17 22:12 ` Junio C Hamano
2024-05-21 5:58 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240510165526.1412338-2-gitster@pobox.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).