1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
|
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<meta name="generator" content="AsciiDoc 10.2.0" />
<title>Submitting Patches</title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
/* Default font. */
body {
font-family: Georgia,serif;
}
/* Title font. */
h1, h2, h3, h4, h5, h6,
div.title, caption.title,
thead, p.table.header,
#toctitle,
#author, #revnumber, #revdate, #revremark,
#footer {
font-family: Arial,Helvetica,sans-serif;
}
body {
margin: 1em 5% 1em 5%;
}
a {
color: blue;
text-decoration: underline;
}
a:visited {
color: fuchsia;
}
em {
font-style: italic;
color: navy;
}
strong {
font-weight: bold;
color: #083194;
}
h1, h2, h3, h4, h5, h6 {
color: #527bbd;
margin-top: 1.2em;
margin-bottom: 0.5em;
line-height: 1.3;
}
h1, h2, h3 {
border-bottom: 2px solid silver;
}
h2 {
padding-top: 0.5em;
}
h3 {
float: left;
}
h3 + * {
clear: left;
}
h5 {
font-size: 1.0em;
}
div.sectionbody {
margin-left: 0;
}
hr {
border: 1px solid silver;
}
p {
margin-top: 0.5em;
margin-bottom: 0.5em;
}
ul, ol, li > p {
margin-top: 0;
}
ul > li { color: #aaa; }
ul > li > * { color: black; }
.monospaced, code, pre {
font-family: "Courier New", Courier, monospace;
font-size: inherit;
color: navy;
padding: 0;
margin: 0;
}
pre {
white-space: pre-wrap;
}
#author {
color: #527bbd;
font-weight: bold;
font-size: 1.1em;
}
#email {
}
#revnumber, #revdate, #revremark {
}
#footer {
font-size: small;
border-top: 2px solid silver;
padding-top: 0.5em;
margin-top: 4.0em;
}
#footer-text {
float: left;
padding-bottom: 0.5em;
}
#footer-badges {
float: right;
padding-bottom: 0.5em;
}
#preamble {
margin-top: 1.5em;
margin-bottom: 1.5em;
}
div.imageblock, div.exampleblock, div.verseblock,
div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
div.admonitionblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.admonitionblock {
margin-top: 2.0em;
margin-bottom: 2.0em;
margin-right: 10%;
color: #606060;
}
div.content { /* Block element content. */
padding: 0;
}
/* Block element titles. */
div.title, caption.title {
color: #527bbd;
font-weight: bold;
text-align: left;
margin-top: 1.0em;
margin-bottom: 0.5em;
}
div.title + * {
margin-top: 0;
}
td div.title:first-child {
margin-top: 0.0em;
}
div.content div.title:first-child {
margin-top: 0.0em;
}
div.content + div.title {
margin-top: 0.0em;
}
div.sidebarblock > div.content {
background: #ffffee;
border: 1px solid #dddddd;
border-left: 4px solid #f0f0f0;
padding: 0.5em;
}
div.listingblock > div.content {
border: 1px solid #dddddd;
border-left: 5px solid #f0f0f0;
background: #f8f8f8;
padding: 0.5em;
}
div.quoteblock, div.verseblock {
padding-left: 1.0em;
margin-left: 1.0em;
margin-right: 10%;
border-left: 5px solid #f0f0f0;
color: #888;
}
div.quoteblock > div.attribution {
padding-top: 0.5em;
text-align: right;
}
div.verseblock > pre.content {
font-family: inherit;
font-size: inherit;
}
div.verseblock > div.attribution {
padding-top: 0.75em;
text-align: left;
}
/* DEPRECATED: Pre version 8.2.7 verse style literal block. */
div.verseblock + div.attribution {
text-align: left;
}
div.admonitionblock .icon {
vertical-align: top;
font-size: 1.1em;
font-weight: bold;
text-decoration: underline;
color: #527bbd;
padding-right: 0.5em;
}
div.admonitionblock td.content {
padding-left: 0.5em;
border-left: 3px solid #dddddd;
}
div.exampleblock > div.content {
border-left: 3px solid #dddddd;
padding-left: 0.5em;
}
div.imageblock div.content { padding-left: 0; }
span.image img { border-style: none; vertical-align: text-bottom; }
a.image:visited { color: white; }
dl {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
dt {
margin-top: 0.5em;
margin-bottom: 0;
font-style: normal;
color: navy;
}
dd > *:first-child {
margin-top: 0.1em;
}
ul, ol {
list-style-position: outside;
}
ol.arabic {
list-style-type: decimal;
}
ol.loweralpha {
list-style-type: lower-alpha;
}
ol.upperalpha {
list-style-type: upper-alpha;
}
ol.lowerroman {
list-style-type: lower-roman;
}
ol.upperroman {
list-style-type: upper-roman;
}
div.compact ul, div.compact ol,
div.compact p, div.compact p,
div.compact div, div.compact div {
margin-top: 0.1em;
margin-bottom: 0.1em;
}
tfoot {
font-weight: bold;
}
td > div.verse {
white-space: pre;
}
div.hdlist {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
div.hdlist tr {
padding-bottom: 15px;
}
dt.hdlist1.strong, td.hdlist1.strong {
font-weight: bold;
}
td.hdlist1 {
vertical-align: top;
font-style: normal;
padding-right: 0.8em;
color: navy;
}
td.hdlist2 {
vertical-align: top;
}
div.hdlist.compact tr {
margin: 0;
padding-bottom: 0;
}
.comment {
background: yellow;
}
.footnote, .footnoteref {
font-size: 0.8em;
}
span.footnote, span.footnoteref {
vertical-align: super;
}
#footnotes {
margin: 20px 0 20px 0;
padding: 7px 0 0 0;
}
#footnotes div.footnote {
margin: 0 0 5px 0;
}
#footnotes hr {
border: none;
border-top: 1px solid silver;
height: 1px;
text-align: left;
margin-left: 0;
width: 20%;
min-width: 100px;
}
div.colist td {
padding-right: 0.5em;
padding-bottom: 0.3em;
vertical-align: top;
}
div.colist td img {
margin-top: 0.3em;
}
@media print {
#footer-badges { display: none; }
}
#toc {
margin-bottom: 2.5em;
}
#toctitle {
color: #527bbd;
font-size: 1.1em;
font-weight: bold;
margin-top: 1.0em;
margin-bottom: 0.1em;
}
div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
margin-top: 0;
margin-bottom: 0;
}
div.toclevel2 {
margin-left: 2em;
font-size: 0.9em;
}
div.toclevel3 {
margin-left: 4em;
font-size: 0.9em;
}
div.toclevel4 {
margin-left: 6em;
font-size: 0.9em;
}
span.aqua { color: aqua; }
span.black { color: black; }
span.blue { color: blue; }
span.fuchsia { color: fuchsia; }
span.gray { color: gray; }
span.green { color: green; }
span.lime { color: lime; }
span.maroon { color: maroon; }
span.navy { color: navy; }
span.olive { color: olive; }
span.purple { color: purple; }
span.red { color: red; }
span.silver { color: silver; }
span.teal { color: teal; }
span.white { color: white; }
span.yellow { color: yellow; }
span.aqua-background { background: aqua; }
span.black-background { background: black; }
span.blue-background { background: blue; }
span.fuchsia-background { background: fuchsia; }
span.gray-background { background: gray; }
span.green-background { background: green; }
span.lime-background { background: lime; }
span.maroon-background { background: maroon; }
span.navy-background { background: navy; }
span.olive-background { background: olive; }
span.purple-background { background: purple; }
span.red-background { background: red; }
span.silver-background { background: silver; }
span.teal-background { background: teal; }
span.white-background { background: white; }
span.yellow-background { background: yellow; }
span.big { font-size: 2em; }
span.small { font-size: 0.6em; }
span.underline { text-decoration: underline; }
span.overline { text-decoration: overline; }
span.line-through { text-decoration: line-through; }
div.unbreakable { page-break-inside: avoid; }
/*
* xhtml11 specific
*
* */
div.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.tableblock > table {
border: 3px solid #527bbd;
}
thead, p.table.header {
font-weight: bold;
color: #527bbd;
}
p.table {
margin-top: 0;
}
/* Because the table frame attribute is overridden by CSS in most browsers. */
div.tableblock > table[frame="void"] {
border-style: none;
}
div.tableblock > table[frame="hsides"] {
border-left-style: none;
border-right-style: none;
}
div.tableblock > table[frame="vsides"] {
border-top-style: none;
border-bottom-style: none;
}
/*
* html5 specific
*
* */
table.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
thead, p.tableblock.header {
font-weight: bold;
color: #527bbd;
}
p.tableblock {
margin-top: 0;
}
table.tableblock {
border-width: 3px;
border-spacing: 0px;
border-style: solid;
border-color: #527bbd;
border-collapse: collapse;
}
th.tableblock, td.tableblock {
border-width: 1px;
padding: 4px;
border-style: solid;
border-color: #527bbd;
}
table.tableblock.frame-topbot {
border-left-style: hidden;
border-right-style: hidden;
}
table.tableblock.frame-sides {
border-top-style: hidden;
border-bottom-style: hidden;
}
table.tableblock.frame-none {
border-style: hidden;
}
th.tableblock.halign-left, td.tableblock.halign-left {
text-align: left;
}
th.tableblock.halign-center, td.tableblock.halign-center {
text-align: center;
}
th.tableblock.halign-right, td.tableblock.halign-right {
text-align: right;
}
th.tableblock.valign-top, td.tableblock.valign-top {
vertical-align: top;
}
th.tableblock.valign-middle, td.tableblock.valign-middle {
vertical-align: middle;
}
th.tableblock.valign-bottom, td.tableblock.valign-bottom {
vertical-align: bottom;
}
/*
* manpage specific
*
* */
body.manpage h1 {
padding-top: 0.5em;
padding-bottom: 0.5em;
border-top: 2px solid silver;
border-bottom: 2px solid silver;
}
body.manpage h2 {
border-style: none;
}
body.manpage div.sectionbody {
margin-left: 3em;
}
@media print {
body.manpage div#toc { display: none; }
}
</style>
<script type="text/javascript">
/*<+'])');
// Function that scans the DOM tree for header elements (the DOM2
// nodeIterator API would be a better technique but not supported by all
// browsers).
var iterate = function (el) {
for (var i = el.firstChild; i != null; i = i.nextSibling) {
if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
var mo = re.exec(i.tagName);
if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
}
iterate(i);
}
}
}
iterate(el);
return result;
}
var toc = document.getElementById("toc");
if (!toc) {
return;
}
// Delete existing TOC entries in case we're reloading the TOC.
var tocEntriesToRemove = [];
var i;
for (i = 0; i < toc.childNodes.length; i++) {
var entry = toc.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div'
&& entry.getAttribute("class")
&& entry.getAttribute("class").match(/^toclevel/))
tocEntriesToRemove.push(entry);
}
for (i = 0; i < tocEntriesToRemove.length; i++) {
toc.removeChild(tocEntriesToRemove[i]);
}
// Rebuild TOC entries.
var entries = tocEntries(document.getElementById("content"), toclevels);
for (var i = 0; i < entries.length; ++i) {
var entry = entries[i];
if (entry.element.id == "")
entry.element.id = "_toc_" + i;
var a = document.createElement("a");
a.href = "#" + entry.element.id;
a.appendChild(document.createTextNode(entry.text));
var div = document.createElement("div");
div.appendChild(a);
div.className = "toclevel" + entry.toclevel;
toc.appendChild(div);
}
if (entries.length == 0)
toc.parentNode.removeChild(toc);
},
/////////////////////////////////////////////////////////////////////
// Footnotes generator
/////////////////////////////////////////////////////////////////////
/* Based on footnote generation code from:
* http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
*/
footnotes: function () {
// Delete existing footnote entries in case we're reloading the footnodes.
var i;
var noteholder = document.getElementById("footnotes");
if (!noteholder) {
return;
}
var entriesToRemove = [];
for (i = 0; i < noteholder.childNodes.length; i++) {
var entry = noteholder.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
entriesToRemove.push(entry);
}
for (i = 0; i < entriesToRemove.length; i++) {
noteholder.removeChild(entriesToRemove[i]);
}
// Rebuild footnote entries.
var cont = document.getElementById("content");
var spans = cont.getElementsByTagName("span");
var refs = {};
var n = 0;
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnote") {
n++;
var note = spans[i].getAttribute("data-note");
if (!note) {
// Use [\s\S] in place of . so multi-line matches work.
// Because JavaScript has no s (dotall) regex flag.
note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
spans[i].innerHTML =
"[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
spans[i].setAttribute("data-note", note);
}
noteholder.innerHTML +=
"<div class='footnote' id='_footnote_" + n + "'>" +
"<a href='#_footnoteref_" + n + "' title='Return to text'>" +
n + "</a>. " + note + "</div>";
var id =spans[i].getAttribute("id");
if (id != null) refs["#"+id] = n;
}
}
if (n == 0)
noteholder.parentNode.removeChild(noteholder);
else {
// Process footnoterefs.
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnoteref") {
var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
href = href.match(/#.*/)[0]; // Because IE return full URL.
n = refs[href];
spans[i].innerHTML =
"[<a href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
}
}
}
},
install: function(toclevels) {
var timerId;
function reinstall() {
asciidoc.footnotes();
if (toclevels) {
asciidoc.toc(toclevels);
}
}
function reinstallAndRemoveTimer() {
clearInterval(timerId);
reinstall();
}
timerId = setInterval(reinstall, 500);
if (document.addEventListener)
document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
else
window.onload = reinstallAndRemoveTimer;
}
}
asciidoc.install();
/*]]>*/
</script>
</head>
<body class="article">
<div id="header">
<h1>Submitting Patches</h1>
<span id="revdate">2024-05-13</span>
</div>
<div id="content">
<div class="sect1">
<h2 id="_guidelines">Guidelines</h2>
<div class="sectionbody">
<div class="paragraph"><p>Here are some guidelines for contributing back to this
project. There is also a <a href="MyFirstContribution.html">step-by-step tutorial</a>
available which covers many of these same guidelines.</p></div>
<div class="sect2">
<h3 id="choose-starting-point">Choose a starting point.</h3>
<div class="paragraph"><p>As a preliminary step, you must first choose a starting point for your
work. Typically this means choosing a branch, although technically
speaking it is actually a particular commit (typically the HEAD, or tip,
of the branch).</p></div>
<div class="paragraph"><p>There are several important branches to be aware of. Namely, there are
four integration branches as discussed in <a href="gitworkflows.html">gitworkflows(7)</a>:</p></div>
<div class="ulist"><ul>
<li>
<p>
maint
</p>
</li>
<li>
<p>
master
</p>
</li>
<li>
<p>
next
</p>
</li>
<li>
<p>
seen
</p>
</li>
</ul></div>
<div class="paragraph"><p>The branches lower on the list are typically descendants of the ones
that come before it. For example, <code>maint</code> is an "older" branch than
<code>master</code> because <code>master</code> usually has patches (commits) on top of
<code>maint</code>.</p></div>
<div class="paragraph"><p>There are also "topic" branches, which contain work from other
contributors. Topic branches are created by the Git maintainer (in
their fork) to organize the current set of incoming contributions on
the mailing list, and are itemized in the regular "What’s cooking in
git.git" announcements. To find the tip of a topic branch, run <code>git log
--first-parent master..seen</code> and look for the merge commit. The second
parent of this commit is the tip of the topic branch.</p></div>
<div class="paragraph"><p>There is one guiding principle for choosing the right starting point: in
general, always base your work on the oldest integration branch that
your change is relevant to (see "Merge upwards" in
<a href="gitworkflows.html">gitworkflows(7)</a>). What this principle means is that for the
vast majority of cases, the starting point for new work should be the
latest HEAD commit of <code>maint</code> or <code>master</code> based on the following cases:</p></div>
<div class="ulist"><ul>
<li>
<p>
If you are fixing bugs in the released version, use <code>maint</code> as the
starting point (which may mean you have to fix things without using
new API features on the cutting edge that recently appeared in
<code>master</code> but were not available in the released version).
</p>
</li>
<li>
<p>
Otherwise (such as if you are adding new features) use <code>master</code>.
</p>
</li>
</ul></div>
<div class="admonitionblock">
<table><tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">In exceptional cases, a bug that was introduced in an old
version may have to be fixed for users of releases that are much older
than the recent releases. <code>git describe --contains X</code> may describe
<code>X</code> as <code>v2.30.0-rc2-gXXXXXX</code> for the commit <code>X</code> that introduced the
bug, and the bug may be so high-impact that we may need to issue a new
maintenance release for Git 2.30.x series, when "Git 2.41.0" is the
current release. In such a case, you may want to use the tip of the
maintenance branch for the 2.30.x series, which may be available in the
<code>maint-2.30</code> branch in <a href="https://github.com/gitster/git">the maintainer’s
"broken out" repo</a>.</td>
</tr></table>
</div>
<div class="paragraph"><p>This also means that <code>next</code> or <code>seen</code> are inappropriate starting points
for your work, if you want your work to have a realistic chance of
graduating to <code>master</code>. They are simply not designed to be used as a
base for new work; they are only there to make sure that topics in
flight work well together. This is why both <code>next</code> and <code>seen</code> are
frequently re-integrated with incoming patches on the mailing list and
force-pushed to replace previous versions of themselves. A topic that is
literally built on top of <code>next</code> cannot be merged to <code>master</code> without
dragging in all the other topics in <code>next</code>, some of which may not be
ready.</p></div>
<div class="paragraph"><p>For example, if you are making tree-wide changes, while somebody else is
also making their own tree-wide changes, your work may have severe
overlap with the other person’s work. This situation may tempt you to
use <code>next</code> as your starting point (because it would have the other
person’s work included in it), but doing so would mean you’ll not only
depend on the other person’s work, but all the other random things from
other contributors that are already integrated into <code>next</code>. And as soon
as <code>next</code> is updated with a new version, all of your work will need to
be rebased anyway in order for them to be cleanly applied by the
maintainer.</p></div>
<div class="paragraph"><p>Under truly exceptional circumstances where you absolutely must depend
on a select few topic branches that are already in <code>next</code> but not in
<code>master</code>, you may want to create your own custom base-branch by forking
<code>master</code> and merging the required topic branches into it. You could then
work on top of this base-branch. But keep in mind that this base-branch
would only be known privately to you. So when you are ready to send
your patches to the list, be sure to communicate how you created it in
your cover letter. This critical piece of information would allow
others to recreate your base-branch on their end in order for them to
try out your work.</p></div>
<div class="paragraph"><p>Finally, note that some parts of the system have dedicated maintainers
with their own separate source code repositories (see the section
"Subsystems" below).</p></div>
</div>
<div class="sect2">
<h3 id="separate-commits">Make separate commits for logically separate changes.</h3>
<div class="paragraph"><p>Unless your patch is really trivial, you should not be sending
out a patch that was generated between your working tree and
your commit head. Instead, always make a commit with complete
commit message and generate a series of patches from your
repository. It is a good discipline.</p></div>
<div class="paragraph"><p>Give an explanation for the change(s) that is detailed enough so
that people can judge if it is good thing to do, without reading
the actual patch text to determine how well the code does what
the explanation promises to do.</p></div>
<div class="paragraph"><p>If your description starts to get too long, that’s a sign that you
probably need to split up your commit to finer grained pieces.
That being said, patches which plainly describe the things that
help reviewers check the patch, and future maintainers understand
the code, are the most beautiful patches. Descriptions that summarize
the point in the subject well, and describe the motivation for the
change, the approach taken by the change, and if relevant how this
differs substantially from the prior version, are all good things
to have.</p></div>
<div class="paragraph"><p>Make sure that you have tests for the bug you are fixing. See
<code>t/README</code> for guidance.</p></div>
<div class="paragraph" id="tests"><p>When adding a new feature, make sure that you have new tests to show
the feature triggers the new behavior when it should, and to show the
feature does not trigger when it shouldn’t. After any code change,
make sure that the entire test suite passes. When fixing a bug, make
sure you have new tests that break if somebody else breaks what you
fixed by accident to avoid regression. Also, try merging your work to
<em>next</em> and <em>seen</em> and make sure the tests still pass; topics by others
that are still in flight may have unexpected interactions with what
you are trying to do in your topic.</p></div>
<div class="paragraph"><p>Pushing to a fork of <a href="https://github.com/git/git">https://github.com/git/git</a> will use their CI
integration to test your changes on Linux, Mac and Windows. See the
<a href="#GHCI">GitHub CI</a> section for details.</p></div>
<div class="paragraph"><p>Do not forget to update the documentation to describe the updated
behavior and make sure that the resulting documentation set formats
well (try the Documentation/doc-diff script).</p></div>
<div class="paragraph"><p>We currently have a liberal mixture of US and UK English norms for
spelling and grammar, which is somewhat unfortunate. A huge patch that
touches the files all over the place only to correct the inconsistency
is not welcome, though. Potential clashes with other changes that can
result from such a patch are not worth it. We prefer to gradually
reconcile the inconsistencies in favor of US English, with small and
easily digestible patches, as a side effect of doing some other real
work in the vicinity (e.g. rewriting a paragraph for clarity, while
turning en_UK spelling to en_US). Obvious typographical fixes are much
more welcomed ("teh → "the"), preferably submitted as independent
patches separate from other documentation changes.</p></div>
<div class="paragraph" id="whitespace-check"><p>Oh, another thing. We are picky about whitespaces. Make sure your
changes do not trigger errors with the sample pre-commit hook shipped
in <code>templates/hooks--pre-commit</code>. To help ensure this does not happen,
run <code>git diff --check</code> on your changes before you commit.</p></div>
</div>
<div class="sect2">
<h3 id="describe-changes">Describe your changes well.</h3>
<div class="paragraph"><p>The log message that explains your changes is just as important as the
changes themselves. Your code may be clearly written with in-code
comment to sufficiently explain how it works with the surrounding
code, but those who need to fix or enhance your code in the future
will need to know <em>why</em> your code does what it does, for a few
reasons:</p></div>
<div class="olist arabic"><ol class="arabic">
<li>
<p>
Your code may be doing something differently from what you wanted it
to do. Writing down what you actually wanted to achieve will help
them fix your code and make it do what it should have been doing
(also, you often discover your own bugs yourself, while writing the
log message to summarize the thought behind it).
</p>
</li>
<li>
<p>
Your code may be doing things that were only necessary for your
immediate needs (e.g. "do X to directories" without implementing or
even designing what is to be done on files). Writing down why you
excluded what the code does not do will help guide future developers.
Writing down "we do X to directories, because directories have
characteristic Y" would help them infer "oh, files also have the same
characteristic Y, so perhaps doing X to them would also make sense?".
Saying "we don’t do the same X to files, because …" will help them
decide if the reasoning is sound (in which case they do not waste
time extending your code to cover files), or reason differently (in
which case, they can explain why they extend your code to cover
files, too).
</p>
</li>
</ol></div>
<div class="paragraph"><p>The goal of your log message is to convey the <em>why</em> behind your
change to help future developers.</p></div>
<div class="paragraph"><p>The first line of the commit message should be a short description (50
characters is the soft limit, see DISCUSSION in <a href="git-commit.html">git-commit(1)</a>),
and should skip the full stop. It is also conventional in most cases to
prefix the first line with "area: " where the area is a filename or
identifier for the general area of the code being modified, e.g.</p></div>
<div class="ulist"><ul>
<li>
<p>
doc: clarify distinction between sign-off and pgp-signing
</p>
</li>
<li>
<p>
githooks.txt: improve the intro section
</p>
</li>
</ul></div>
<div class="paragraph"><p>If in doubt which identifier to use, run <code>git log --no-merges</code> on the
files you are modifying to see the current conventions.</p></div>
<div class="paragraph" id="summary-section"><p>The title sentence after the "area:" prefix omits the full stop at the
end, and its first word is not capitalized (the omission
of capitalization applies only to the word after the "area:"
prefix of the title) unless there is a reason to
capitalize it other than because it is the first word in the sentence.
E.g. "doc: clarify…", not "doc: Clarify…", or "githooks.txt:
improve…", not "githooks.txt: Improve…". But "refs: HEAD is also
treated as a ref" is correct, as we spell <code>HEAD</code> in all caps even when
it appears in the middle of a sentence.</p></div>
<div class="paragraph" id="meaningful-message"><p>The body should provide a meaningful commit message, which:</p></div>
<div class="olist arabic"><ol class="arabic">
<li>
<p>
explains the problem the change tries to solve, i.e. what is wrong
with the current code without the change.
</p>
</li>
<li>
<p>
justifies the way the change solves the problem, i.e. why the
result with the change is better.
</p>
</li>
<li>
<p>
alternate solutions considered but discarded, if any.
</p>
</li>
</ol></div>
<div class="paragraph" id="present-tense"><p>The problem statement that describes the status quo is written in the
present tense. Write "The code does X when it is given input Y",
instead of "The code used to do Y when given input X". You do not
have to say "Currently"---the status quo in the problem statement is
about the code <em>without</em> your change, by project convention.</p></div>
<div class="paragraph" id="imperative-mood"><p>Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behavior. Try to make sure your explanation can be understood
without external resources. Instead of giving a URL to a mailing list
archive, summarize the relevant points of the discussion.</p></div>
<div class="paragraph" id="commit-reference"><p>There are a few reasons why you may want to refer to another commit in
the "more stable" part of the history (i.e. on branches like <code>maint</code>,
<code>master</code>, and <code>next</code>):</p></div>
<div class="olist arabic"><ol class="arabic">
<li>
<p>
A commit that introduced the root cause of a bug you are fixing.
</p>
</li>
<li>
<p>
A commit that introduced a feature that you are enhancing.
</p>
</li>
<li>
<p>
A commit that conflicts with your work when you made a trial merge
of your work into <code>next</code> and <code>seen</code> for testing.
</p>
</li>
</ol></div>
<div class="paragraph"><p>When you reference a commit on a more stable branch (like <code>master</code>,
<code>maint</code> and <code>next</code>), use the format "abbreviated hash (subject,
date)", like this:</p></div>
<div class="literalblock">
<div class="content">
<pre><code> Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30)
noticed that ...</code></pre>
</div></div>
<div class="paragraph"><p>The "Copy commit reference" command of gitk can be used to obtain this
format (with the subject enclosed in a pair of double-quotes), or this
invocation of <code>git show</code>:</p></div>
<div class="literalblock">
<div class="content">
<pre><code> git show -s --pretty=reference <commit></code></pre>
</div></div>
<div class="paragraph"><p>or, on an older version of Git without support for --pretty=reference:</p></div>
<div class="literalblock">
<div class="content">
<pre><code> git show -s --date=short --pretty='format:%h (%s, %ad)' <commit></code></pre>
</div></div>
</div>
<div class="sect2">
<h3 id="sign-off">Certify your work by adding your <code>Signed-off-by</code> trailer</h3>
<div class="paragraph"><p>To improve tracking of who did what, we ask you to certify that you
wrote the patch or have the right to pass it on under the same license
as ours, by "signing off" your patch. Without sign-off, we cannot
accept your patches.</p></div>
<div class="paragraph"><p>If (and only if) you certify the below D-C-O:</p></div>
<div class="quoteblock" id="dco">
<div class="title">Developer’s Certificate of Origin 1.1</div>
<div class="content">
<div class="paragraph"><p>By making a contribution to this project, I certify that:</p></div>
<div class="olist loweralpha"><ol class="loweralpha">
<li>
<p>
The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
</p>
</li>
<li>
<p>
The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
</p>
</li>
<li>
<p>
The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
</p>
</li>
<li>
<p>
I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
</p>
</li>
</ol></div>
</div>
<div class="attribution">
</div></div>
<div class="paragraph"><p>you add a "Signed-off-by" trailer to your commit, that looks like
this:</p></div>
<div class="literalblock">
<div class="content">
<pre><code> Signed-off-by: Random J Developer <random@developer.example.org></code></pre>
</div></div>
<div class="paragraph"><p>This line can be added by Git if you run the git-commit command with
the -s option.</p></div>
<div class="paragraph"><p>Notice that you can place your own <code>Signed-off-by</code> trailer when
forwarding somebody else’s patch with the above rules for
D-C-O. Indeed you are encouraged to do so. Do not forget to
place an in-body "From: " line at the beginning to properly attribute
the change to its true author (see (2) above).</p></div>
<div class="paragraph"><p>This procedure originally came from the Linux kernel project, so our
rule is quite similar to theirs, but what exactly it means to sign-off
your patch differs from project to project, so it may be different
from that of the project you are accustomed to.</p></div>
<div class="paragraph" id="real-name"><p>Also notice that a real name is used in the <code>Signed-off-by</code> trailer. Please
don’t hide your real name.</p></div>
<div class="paragraph" id="commit-trailers"><p>If you like, you can put extra tags at the end:</p></div>
<div class="olist arabic"><ol class="arabic">
<li>
<p>
<code>Reported-by:</code> is used to credit someone who found the bug that
the patch attempts to fix.
</p>
</li>
<li>
<p>
<code>Acked-by:</code> says that the person who is more familiar with the area
the patch attempts to modify liked the patch.
</p>
</li>
<li>
<p>
<code>Reviewed-by:</code>, unlike the other tags, can only be offered by the
reviewers themselves when they are completely satisfied with the
patch after a detailed analysis.
</p>
</li>
<li>
<p>
<code>Tested-by:</code> is used to indicate that the person applied the patch
and found it to have the desired effect.
</p>
</li>
<li>
<p>
<code>Co-authored-by:</code> is used to indicate that people exchanged drafts
of a patch before submitting it.
</p>
</li>
<li>
<p>
<code>Helped-by:</code> is used to credit someone who suggested ideas for
changes without providing the precise changes in patch form.
</p>
</li>
<li>
<p>
<code>Mentored-by:</code> is used to credit someone with helping develop a
patch as part of a mentorship program (e.g., GSoC or Outreachy).
</p>
</li>
<li>
<p>
<code>Suggested-by:</code> is used to credit someone with suggesting the idea
for a patch.
</p>
</li>
</ol></div>
<div class="paragraph"><p>While you can also create your own trailer if the situation warrants it, we
encourage you to instead use one of the common trailers in this project
highlighted above.</p></div>
<div class="paragraph"><p>Only capitalize the very first letter of tags, i.e. favor
"Signed-off-by" over "Signed-Off-By" and "Acked-by:" over "Acked-By".</p></div>
</div>
<div class="sect2">
<h3 id="git-tools">Generate your patch using Git tools out of your commits.</h3>
<div class="paragraph"><p>Git based diff tools generate unidiff which is the preferred format.</p></div>
<div class="paragraph"><p>You do not have to be afraid to use <code>-M</code> option to <code>git diff</code> or
<code>git format-patch</code>, if your patch involves file renames. The
receiving end can handle them just fine.</p></div>
<div class="paragraph" id="review-patch"><p>Please make sure your patch does not add commented out debugging code,
or include any extra files which do not relate to what your patch
is trying to achieve. Make sure to review
your patch after generating it, to ensure accuracy. Before
sending out, please make sure it cleanly applies to the starting point you
have chosen in the "Choose a starting point" section.</p></div>
<div class="admonitionblock">
<table><tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">From the perspective of those reviewing your patch, the <code>master</code>
branch is the default expected starting point. So if you have chosen a
different starting point, please communicate this choice in your cover
letter.</td>
</tr></table>
</div>
</div>
<div class="sect2">
<h3 id="send-patches">Sending your patches.</h3>
<div class="sect3">
<h4 id="_choosing_your_reviewers">Choosing your reviewers</h4>
<div class="admonitionblock">
<table><tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">Patches that may be
security relevant should be submitted privately to the Git Security
mailing list<span class="footnote" id="_footnote_security-ml"><br />[The Git Security mailing list: <a href="mailto:git-security@googlegroups.com">git-security@googlegroups.com</a>]<br /></span>, instead of the public mailing list.</td>
</tr></table>
</div>
<div class="paragraph"><p>Send your patch with "To:" set to the mailing list, with "cc:" listing
people who are involved in the area you are touching (the <code>git-contacts</code>
script in <code>contrib/contacts/</code><span class="footnote" id="_footnote_contrib-scripts"><br />[Scripts under <code>contrib/</code> are not part of the core <code>git</code> binary and must be called directly. Clone the Git codebase and run <code>perl contrib/contacts/git-contacts</code>.]<br /></span> can help to
identify them), to solicit comments and reviews. Also, when you made
trial merges of your topic to <code>next</code> and <code>seen</code>, you may have noticed
work by others conflicting with your changes. There is a good possibility
that these people may know the area you are touching well.</p></div>
<div class="paragraph"><p>If you are using <code>send-email</code>, you can feed it the output of <code>git-contacts</code> like
this:</p></div>
<div class="literalblock">
<div class="content">
<pre><code> git send-email --cc-cmd='perl contrib/contacts/git-contacts' feature/*.patch</code></pre>
</div></div>
<div class="paragraph"><p>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<span class="footnote"><br />[The current maintainer: <a href="mailto:gitster@pobox.com">gitster@pobox.com</a>]<br /></span>
and "cc:" the list<span class="footnote"><br />[The mailing list: <a href="mailto:git@vger.kernel.org">git@vger.kernel.org</a>]<br /></span> for inclusion. This is especially relevant
when the maintainer did not heavily participate in the discussion and
instead left the review to trusted others.</p></div>
<div class="paragraph"><p>Do not forget to add trailers such as <code>Acked-by:</code>, <code>Reviewed-by:</code> and
<code>Tested-by:</code> lines as necessary to credit people who helped your
patch, and "cc:" them when sending such a final version for inclusion.</p></div>
</div>
<div class="sect3">
<h4 id="_code_format_patch_code_and_code_send_email_code"><code>format-patch</code> and <code>send-email</code></h4>
<div class="paragraph"><p>Learn to use <code>format-patch</code> and <code>send-email</code> if possible. These commands
are optimized for the workflow of sending patches, avoiding many ways
your existing e-mail client (often optimized for "multipart/*" MIME
type e-mails) might render your patches unusable.</p></div>
<div class="admonitionblock">
<table><tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">Here we outline the procedure using <code>format-patch</code> and
<code>send-email</code>, but you can instead use GitGitGadget to send in your
patches (see <a href="MyFirstContribution.html">MyFirstContribution</a>).</td>
</tr></table>
</div>
<div class="paragraph"><p>People on the Git mailing list need to be able to read and
comment on the changes you are submitting. It is important for
a developer to be able to "quote" your changes, using standard
e-mail tools, so that they may comment on specific portions of
your code. For this reason, each patch should be submitted
"inline" in a separate message.</p></div>
<div class="paragraph"><p>All subsequent versions of a patch series and other related patches should be
grouped into their own e-mail thread to help readers find all parts of the
series. To that end, send them as replies to either an additional "cover
letter" message (see below), the first patch, or the respective preceding patch.
Here is a <a href="MyFirstContribution.html#v2-git-send-email">step-by-step guide</a> on
how to submit updated versions of a patch series.</p></div>
<div class="paragraph"><p>If your log message (including your name on the
<code>Signed-off-by</code> trailer) is not writable in ASCII, make sure that
you send off a message in the correct encoding.</p></div>
<div class="admonitionblock">
<table><tr>
<td class="icon">
<div class="title">Warning</div>
</td>
<td class="content">Be wary of your MUAs word-wrap
corrupting your patch. Do not cut-n-paste your patch; you can
lose tabs that way if you are not careful.</td>
</tr></table>
</div>
<div class="paragraph"><p>It is a common convention to prefix your subject line with
[PATCH]. This lets people easily distinguish patches from other
e-mail discussions. Use of markers in addition to PATCH within
the brackets to describe the nature of the patch is also
encouraged. E.g. [RFC PATCH] (where RFC stands for "request for
comments") is often used to indicate a patch needs further
discussion before being accepted, [PATCH v2], [PATCH v3] etc.
are often seen when you are sending an update to what you have
previously sent.</p></div>
<div class="paragraph"><p>The <code>git format-patch</code> command follows the best current practice to
format the body of an e-mail message. At the beginning of the
patch should come your commit message, ending with the
<code>Signed-off-by</code> trailers, and a line that consists of three dashes,
followed by the diffstat information and the patch itself. If
you are forwarding a patch from somebody else, optionally, at
the beginning of the e-mail message just before the commit
message starts, you can put a "From: " line to name that person.
To change the default "[PATCH]" in the subject to "[<text>]", use
<code>git format-patch --subject-prefix=<text></code>. As a shortcut, you
can use <code>--rfc</code> instead of <code>--subject-prefix="RFC PATCH"</code>, or
<code>-v <n></code> instead of <code>--subject-prefix="PATCH v<n>"</code>.</p></div>
<div class="paragraph"><p>You often want to add additional explanation about the patch,
other than the commit message itself. Place such "cover letter"
material between the three-dash line and the diffstat. For
patches requiring multiple iterations of review and discussion,
an explanation of changes between each iteration can be kept in
Git-notes and inserted automatically following the three-dash
line via <code>git format-patch --notes</code>.</p></div>
<div class="paragraph" id="the-topic-summary"><p><strong>This is EXPERIMENTAL</strong>.</p></div>
<div class="paragraph"><p>When sending a topic, you can propose a one-paragraph summary that
should appear in the "What’s cooking" report when it is picked up to
explain the topic. If you choose to do so, please write a 2-5 line
paragraph that will fit well in our release notes (see many bulleted
entries in the Documentation/RelNotes/* files for examples), and make
it the first paragraph of the cover letter. For a single-patch
series, use the space between the three-dash line and the diffstat, as
described earlier.</p></div>
<div class="paragraph" id="attachment"><p>Do not attach the patch as a MIME attachment, compressed or not.
Do not let your e-mail client send quoted-printable. Do not let
your e-mail client send format=flowed which would destroy
whitespaces in your patches. Many
popular e-mail applications will not always transmit a MIME
attachment as plain text, making it impossible to comment on
your code. A MIME attachment also takes a bit more time to
process. This does not decrease the likelihood of your
MIME-attached change being accepted, but it makes it more likely
that it will be postponed.</p></div>
<div class="paragraph"><p>Exception: If your mailer is mangling patches then someone may ask
you to re-send them using MIME, that is OK.</p></div>
<div class="paragraph" id="pgp-signature"><p>Do not PGP sign your patch. Most likely, your maintainer or other people on the
list would not have your PGP key and would not bother obtaining it anyway.
Your patch is not judged by who you are; a good patch from an unknown origin
has a far better chance of being accepted than a patch from a known, respected
origin that is done poorly or does incorrect things.</p></div>
<div class="paragraph"><p>If you really really really really want to do a PGP signed
patch, format it as "multipart/signed", not a text/plain message
that starts with <code>-----BEGIN PGP SIGNED MESSAGE-----</code>. That is
not a text/plain, it’s something else.</p></div>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_subsystems_with_dedicated_maintainers">Subsystems with dedicated maintainers</h2>
<div class="sectionbody">
<div class="paragraph"><p>Some parts of the system have dedicated maintainers with their own
repositories.</p></div>
<div class="ulist"><ul>
<li>
<p>
<code>git-gui/</code> comes from git-gui project, maintained by Johannes Sixt:
</p>
<div class="literalblock">
<div class="content">
<pre><code>https://github.com/j6t/git-gui</code></pre>
</div></div>
</li>
<li>
<p>
<code>gitk-git/</code> comes from Paul Mackerras’s gitk project:
</p>
<div class="literalblock">
<div class="content">
<pre><code>git://git.ozlabs.org/~paulus/gitk</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>Those who are interested in improving gitk can volunteer to help Paul
maintain it, cf. <YntxL/fTplFm8lr6@cleo>.</code></pre>
</div></div>
</li>
<li>
<p>
<code>po/</code> comes from the localization coordinator, Jiang Xin:
</p>
<div class="literalblock">
<div class="content">
<pre><code>https://github.com/git-l10n/git-po/</code></pre>
</div></div>
</li>
</ul></div>
<div class="paragraph"><p>Patches to these parts should be based on their trees.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="patch-flow">An ideal patch flow</h2>
<div class="sectionbody">
<div class="paragraph"><p>Here is an ideal patch flow for this project the current maintainer
suggests to the contributors:</p></div>
<div class="olist arabic"><ol class="arabic">
<li>
<p>
You come up with an itch. You code it up.
</p>
</li>
<li>
<p>
Send it to the list and cc people who may need to know about
the change.
</p>
<div class="paragraph"><p>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). <code>git log -p -- <em>$area_you_are_modifying</em></code> would
help you find out who they are.</p></div>
</li>
<li>
<p>
You get comments and suggestions for improvements. You may
even get them in an "on top of your change" patch form.
</p>
</li>
<li>
<p>
Polish, refine, and re-send to the list and the people who
spend their time to improve your patch. Go back to step (2).
</p>
</li>
<li>
<p>
The list forms consensus that the last round of your patch is
good. Send it to the maintainer and cc the list.
</p>
</li>
<li>
<p>
A topic branch is created with the patch and is merged to <code>next</code>,
and cooked further and eventually graduates to <code>master</code>.
</p>
</li>
</ol></div>
<div class="paragraph"><p>In any time between the (2)-(3) cycle, the maintainer may pick it up
from the list and queue it to <code>seen</code>, 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.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="patch-status">Know the status of your patch after submission</h2>
<div class="sectionbody">
<div class="ulist"><ul>
<li>
<p>
You can use Git itself to find out when your patch is merged in
master. <code>git pull --rebase</code> 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 <code>seen</code> if you rebase on top of
master).
</p>
</li>
<li>
<p>
Read the Git mailing list, the maintainer regularly posts messages
entitled "What’s cooking in git.git" giving
the status of various proposed changes.
</p>
</li>
</ul></div>
</div>
</div>
<div class="sect1">
<h2 id="_github_ci_a_id_ghci_a">GitHub CI<a id="GHCI"></a></h2>
<div class="sectionbody">
<div class="paragraph"><p>With an account at GitHub, you can use GitHub CI to test your changes
on Linux, Mac and Windows. See
<a href="https://github.com/git/git/actions/workflows/main.yml">https://github.com/git/git/actions/workflows/main.yml</a> for examples of
recent CI runs.</p></div>
<div class="paragraph"><p>Follow these steps for the initial setup:</p></div>
<div class="olist arabic"><ol class="arabic">
<li>
<p>
Fork <a href="https://github.com/git/git">https://github.com/git/git</a> to your GitHub account.
You can find detailed instructions how to fork here:
<a href="https://help.github.com/articles/fork-a-repo/">https://help.github.com/articles/fork-a-repo/</a>
</p>
</li>
</ol></div>
<div class="paragraph"><p>After the initial setup, CI will run whenever you push new changes
to your fork of Git on GitHub. You can monitor the test state of all your
branches here: <code>https://github.com/<Your GitHub handle>/git/actions/workflows/main.yml</code></p></div>
<div class="paragraph"><p>If a branch does not pass all test cases then it will be marked with a
red <code>x</code>, instead of a green check. In that case, you can click on the
failing job and navigate to "ci/run-build-and-tests.sh" and/or
"ci/print-test-failures.sh". You can also download "Artifacts" which
are zip archives containing tarred (or zipped) archives with test data
relevant for debugging.</p></div>
<div class="paragraph"><p>Then fix the problem and push your fix to your GitHub fork. This will
trigger a new CI build to ensure all tests pass.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="mua">MUA specific hints</h2>
<div class="sectionbody">
<div class="paragraph"><p>Some of the patches I receive or pick up from the list share common
patterns of breakage. Please make sure your MUA is set up
properly not to corrupt whitespaces.</p></div>
<div class="paragraph"><p>See the DISCUSSION section of <a href="git-format-patch.html">git-format-patch(1)</a> for hints on
checking your patch by mailing it to yourself and applying with
<a href="git-am.html">git-am(1)</a>.</p></div>
<div class="paragraph"><p>While you are at it, check the resulting commit log message from
a trial run of applying the patch. If what is in the resulting
commit is not exactly what you would want to see, it is very
likely that your maintainer would end up hand editing the log
message when he applies your patch. Things like "Hi, this is my
first patch.\n", if you really want to put in the patch e-mail,
should come after the three-dash line that signals the end of the
commit message.</p></div>
<div class="sect2">
<h3 id="_pine">Pine</h3>
<div class="paragraph"><p>(Johannes Schindelin)</p></div>
<div class="literalblock">
<div class="content">
<pre><code>I don't know how many people still use pine, but for those poor
souls it may be good to mention that the quell-flowed-text is
needed for recent versions.
... the "no-strip-whitespace-before-send" option, too. AFAIK it
was introduced in 4.60.</code></pre>
</div></div>
<div class="paragraph"><p>(Linus Torvalds)</p></div>
<div class="literalblock">
<div class="content">
<pre><code>And 4.58 needs at least this.
diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1)
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Mon Aug 15 17:23:51 2005 -0700
Fix pine whitespace-corruption bug
There's no excuse for unconditionally removing whitespace from
the pico buffers on close.
diff --git a/pico/pico.c b/pico/pico.c
--- a/pico/pico.c
+++ b/pico/pico.c
@@ -219,7 +219,9 @@ PICO *pm;
switch(pico_all_done){ /* prepare for/handle final events */
case COMP_EXIT : /* already confirmed */
packheader();
+#if 0
stripwhitespace();
+#endif
c |= COMP_EXIT;
break;</code></pre>
</div></div>
<div class="paragraph"><p>(Daniel Barkalow)</p></div>
<div class="literalblock">
<div class="content">
<pre><code>> A patch to SubmittingPatches, MUA specific help section for
> users of Pine 4.63 would be very much appreciated.
Ah, it looks like a recent version changed the default behavior to do the
right thing, and inverted the sense of the configuration option. (Either
that or Gentoo did it.) So you need to set the
"no-strip-whitespace-before-send" option, unless the option you have is
"strip-whitespace-before-send", in which case you should avoid checking
it.</code></pre>
</div></div>
</div>
<div class="sect2">
<h3 id="_thunderbird_kmail_gmail">Thunderbird, KMail, GMail</h3>
<div class="paragraph"><p>See the MUA-SPECIFIC HINTS section of <a href="git-format-patch.html">git-format-patch(1)</a>.</p></div>
</div>
<div class="sect2">
<h3 id="_gnus">Gnus</h3>
<div class="paragraph"><p>"|" in the <code>*Summary*</code> buffer can be used to pipe the current
message to an external program, and this is a handy way to drive
<code>git am</code>. However, if the message is MIME encoded, what is
piped into the program is the representation you see in your
<code>*Article*</code> buffer after unwrapping MIME. This is often not what
you would want for two reasons. It tends to screw up non-ASCII
characters (most notably in people’s names), and also
whitespaces (fatal in patches). Running "C-u g" to display the
message in raw form before using "|" to run the pipe can work
this problem around.</p></div>
</div>
</div>
</div>
</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated
2024-05-13 12:26:57 PDT
</div>
</div>
</body>
</html>
|
