SubmittingPatches: move the patch-flow section earlier
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>
Junio C Hamano committed
May 10, 2024 at 09:55 UTC
d58848fb21395ff9b892beeb11f6f2c38e7d2d4b
1 file changed
+49
-49
Documentation/SubmittingPatches
+49
-49
@@ -7,6 +7,55 @@ Here are some guidelines for contributing back to this
7
project. There is also a link:MyFirstContribution.html[step-by-step tutorial]
8
available which covers many of these same guidelines.
9
10
+[[patch-flow]]
11
+=== An ideal patch flow
12
+
13
+Here is an ideal patch flow for this project the current maintainer
14
+suggests to the contributors:
15
+
16
+. You come up with an itch. You code it up.
17
+
18
+. Send it to the list and cc people who may need to know about
19
+ the change.
20
++
21
+The people who may need to know are the ones whose code you
22
+are butchering. These people happen to be the ones who are
23
+most likely to be knowledgeable enough to help you, but
24
+they have no obligation to help you (i.e. you ask for help,
25
+don't demand). +git log -p {litdd} _$area_you_are_modifying_+ would
26
+help you find out who they are.
27
+
28
+. You get comments and suggestions for improvements. You may
29
+ even get them in an "on top of your change" patch form.
30
+
31
+. Polish, refine, and re-send to the list and the people who
32
+ spend their time to improve your patch. Go back to step (2).
33
+
34
+. The list forms consensus that the last round of your patch is
35
+ good. Send it to the maintainer and cc the list.
36
+
37
+. A topic branch is created with the patch and is merged to `next`,
38
+ and cooked further and eventually graduates to `master`.
39
+
40
+In any time between the (2)-(3) cycle, the maintainer may pick it up
41
+from the list and queue it to `seen`, in order to make it easier for
42
+people to play with it without having to pick up and apply the patch to
43
+their trees themselves.
44
+
45
+[[patch-status]]
46
+=== Know the status of your patch after submission
47
+
48
+* You can use Git itself to find out when your patch is merged in
49
+ master. `git pull --rebase` will automatically skip already-applied
50
+ patches, and will let you know. This works only if you rebase on top
51
+ of the branch in which your patch has been merged (i.e. it will not
52
+ tell you if your patch is merged in `seen` if you rebase on top of
53
+ master).
54
+
55
+* Read the Git mailing list, the maintainer regularly posts messages
56
+ entitled "What's cooking in git.git" giving
57
+ the status of various proposed changes.
58
+
59
[[choose-starting-point]]
60
=== Choose a starting point.
61
@@ -562,55 +611,6 @@ repositories.
611
612
Patches to these parts should be based on their trees.
613
565
-[[patch-flow]]
566
-== An ideal patch flow
567
-
568
-Here is an ideal patch flow for this project the current maintainer
569
-suggests to the contributors:
570
-
571
-. You come up with an itch. You code it up.
572
-
573
-. Send it to the list and cc people who may need to know about
574
- the change.
575
-+
576
-The people who may need to know are the ones whose code you
577
-are butchering. These people happen to be the ones who are
578
-most likely to be knowledgeable enough to help you, but
579
-they have no obligation to help you (i.e. you ask for help,
580
-don't demand). +git log -p {litdd} _$area_you_are_modifying_+ would
581
-help you find out who they are.
582
-
583
-. You get comments and suggestions for improvements. You may
584
- even get them in an "on top of your change" patch form.
585
-
586
-. Polish, refine, and re-send to the list and the people who
587
- spend their time to improve your patch. Go back to step (2).
588
-
589
-. The list forms consensus that the last round of your patch is
590
- good. Send it to the maintainer and cc the list.
591
-
592
-. A topic branch is created with the patch and is merged to `next`,
593
- and cooked further and eventually graduates to `master`.
594
-
595
-In any time between the (2)-(3) cycle, the maintainer may pick it up
596
-from the list and queue it to `seen`, in order to make it easier for
597
-people to play with it without having to pick up and apply the patch to
598
-their trees themselves.
599
-
600
-[[patch-status]]
601
-== Know the status of your patch after submission
602
-
603
-* You can use Git itself to find out when your patch is merged in
604
- master. `git pull --rebase` will automatically skip already-applied
605
- patches, and will let you know. This works only if you rebase on top
606
- of the branch in which your patch has been merged (i.e. it will not
607
- tell you if your patch is merged in `seen` if you rebase on top of
608
- master).
609
-
610
-* Read the Git mailing list, the maintainer regularly posts messages
611
- entitled "What's cooking in git.git" giving
612
- the status of various proposed changes.
613
-
614
== GitHub CI[[GHCI]]
615
616
With an account at GitHub, you can use GitHub CI to test your changes