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