| 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 | a85030a | 2022-07-27 16:48:21 | [diff] [blame] | 7 | <meta name="generator" content="AsciiDoc 10.2.0" /> |
| 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 | /*<![CDATA[*/ |
| Junio C Hamano | 2b15318 | 2021-12-15 21:00:31 | [diff] [blame] | 542 | var asciidoc = { // Namespace. |
| 543 | |
| 544 | ///////////////////////////////////////////////////////////////////// |
| 545 | // Table Of Contents generator |
| 546 | ///////////////////////////////////////////////////////////////////// |
| 547 | |
| 548 | /* Author: Mihai Bazon, September 2002 |
| 549 | * http://students.infoiasi.ro/~mishoo |
| 550 | * |
| 551 | * Table Of Content generator |
| 552 | * Version: 0.4 |
| 553 | * |
| 554 | * Feel free to use this script under the terms of the GNU General Public |
| 555 | * License, as long as you do not remove or alter this notice. |
| 556 | */ |
| 557 | |
| 558 | /* modified by Troy D. Hanson, September 2006. License: GPL */ |
| 559 | /* modified by Stuart Rackham, 2006, 2009. License: GPL */ |
| 560 | |
| 561 | // toclevels = 1..4. |
| 562 | toc: function (toclevels) { |
| 563 | |
| 564 | function getText(el) { |
| 565 | var text = ""; |
| 566 | for (var i = el.firstChild; i != null; i = i.nextSibling) { |
| 567 | if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants. |
| 568 | text += i.data; |
| 569 | else if (i.firstChild != null) |
| 570 | text += getText(i); |
| 571 | } |
| 572 | return text; |
| 573 | } |
| 574 | |
| 575 | function TocEntry(el, text, toclevel) { |
| 576 | this.element = el; |
| 577 | this.text = text; |
| 578 | this.toclevel = toclevel; |
| 579 | } |
| 580 | |
| 581 | function tocEntries(el, toclevels) { |
| 582 | var result = new Array; |
| 583 | var re = new RegExp('[hH]([1-'+(toclevels+1)+'])'); |
| 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 | } |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 731 | asciidoc.install(); |
| 732 | /*]]>*/ |
| 733 | </script> |
| 734 | </head> |
| 735 | <body class="article"> |
| 736 | <div id="header"> |
| 737 | <h1>Submitting Patches</h1> |
| Junio C Hamano | 3f8de25 | 2023-08-29 21:20:06 | [diff] [blame^] | 738 | <span id="revdate">2023-08-29</span> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 739 | </div> |
| 740 | <div id="content"> |
| 741 | <div class="sect1"> |
| 742 | <h2 id="_guidelines">Guidelines</h2> |
| 743 | <div class="sectionbody"> |
| Junio C Hamano | 62908fd | 2023-08-04 19:05:22 | [diff] [blame] | 744 | <div class="paragraph"><p>Here are some guidelines for contributing back to this |
| 745 | project. There is also a <a href="MyFirstContribution.html">step-by-step tutorial</a> |
| Junio C Hamano | 64eff49 | 2020-06-18 06:18:50 | [diff] [blame] | 746 | available which covers many of these same guidelines.</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 747 | <div class="sect2"> |
| Junio C Hamano | 62908fd | 2023-08-04 19:05:22 | [diff] [blame] | 748 | <h3 id="choose-starting-point">Choose a starting point.</h3> |
| 749 | <div class="paragraph"><p>As a preliminary step, you must first choose a starting point for your |
| 750 | work. Typically this means choosing a branch, although technically |
| 751 | speaking it is actually a particular commit (typically the HEAD, or tip, |
| 752 | of the branch).</p></div> |
| 753 | <div class="paragraph"><p>There are several important branches to be aware of. Namely, there are |
| 754 | four integration branches as discussed in <a href="gitworkflows.html">gitworkflows(7)</a>:</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 755 | <div class="ulist"><ul> |
| 756 | <li> |
| 757 | <p> |
| Junio C Hamano | 62908fd | 2023-08-04 19:05:22 | [diff] [blame] | 758 | maint |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 759 | </p> |
| 760 | </li> |
| 761 | <li> |
| 762 | <p> |
| Junio C Hamano | 62908fd | 2023-08-04 19:05:22 | [diff] [blame] | 763 | master |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 764 | </p> |
| 765 | </li> |
| 766 | <li> |
| 767 | <p> |
| Junio C Hamano | 62908fd | 2023-08-04 19:05:22 | [diff] [blame] | 768 | next |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 769 | </p> |
| 770 | </li> |
| 771 | <li> |
| 772 | <p> |
| Junio C Hamano | 62908fd | 2023-08-04 19:05:22 | [diff] [blame] | 773 | seen |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 774 | </p> |
| 775 | </li> |
| 776 | </ul></div> |
| Junio C Hamano | 62908fd | 2023-08-04 19:05:22 | [diff] [blame] | 777 | <div class="paragraph"><p>The branches lower on the list are typically descendants of the ones |
| 778 | that come before it. For example, <code>maint</code> is an "older" branch than |
| 779 | <code>master</code> because <code>master</code> usually has patches (commits) on top of |
| 780 | <code>maint</code>.</p></div> |
| 781 | <div class="paragraph"><p>There are also "topic" branches, which contain work from other |
| 782 | contributors. Topic branches are created by the Git maintainer (in |
| 783 | their fork) to organize the current set of incoming contributions on |
| 784 | the mailing list, and are itemized in the regular "What’s cooking in |
| 785 | git.git" announcements. To find the tip of a topic branch, run <code>git log |
| 786 | --first-parent master..seen</code> and look for the merge commit. The second |
| 787 | parent of this commit is the tip of the topic branch.</p></div> |
| 788 | <div class="paragraph"><p>There is one guiding principle for choosing the right starting point: in |
| 789 | general, always base your work on the oldest integration branch that |
| 790 | your change is relevant to (see "Merge upwards" in |
| 791 | <a href="gitworkflows.html">gitworkflows(7)</a>). What this principle means is that for the |
| 792 | vast majority of cases, the starting point for new work should be the |
| 793 | latest HEAD commit of <code>maint</code> or <code>master</code> based on the following cases:</p></div> |
| 794 | <div class="ulist"><ul> |
| 795 | <li> |
| 796 | <p> |
| 797 | If you are fixing bugs in the released version, use <code>maint</code> as the |
| 798 | starting point (which may mean you have to fix things without using |
| 799 | new API features on the cutting edge that recently appeared in |
| 800 | <code>master</code> but were not available in the released version). |
| 801 | </p> |
| 802 | </li> |
| 803 | <li> |
| 804 | <p> |
| 805 | Otherwise (such as if you are adding new features) use <code>master</code>. |
| 806 | </p> |
| 807 | </li> |
| 808 | </ul></div> |
| 809 | <div class="admonitionblock"> |
| 810 | <table><tr> |
| 811 | <td class="icon"> |
| 812 | <div class="title">Note</div> |
| 813 | </td> |
| 814 | <td class="content">In exceptional cases, a bug that was introduced in an old |
| 815 | version may have to be fixed for users of releases that are much older |
| 816 | than the recent releases. <code>git describe --contains X</code> may describe |
| 817 | <code>X</code> as <code>v2.30.0-rc2-gXXXXXX</code> for the commit <code>X</code> that introduced the |
| 818 | bug, and the bug may be so high-impact that we may need to issue a new |
| 819 | maintenance release for Git 2.30.x series, when "Git 2.41.0" is the |
| 820 | current release. In such a case, you may want to use the tip of the |
| 821 | maintenance branch for the 2.30.x series, which may be available in the |
| 822 | <code>maint-2.30</code> branch in <a href="https://github.com/gitster/git">the maintainer’s |
| 823 | "broken out" repo</a>.</td> |
| 824 | </tr></table> |
| 825 | </div> |
| 826 | <div class="paragraph"><p>This also means that <code>next</code> or <code>seen</code> are inappropriate starting points |
| 827 | for your work, if you want your work to have a realistic chance of |
| 828 | graduating to <code>master</code>. They are simply not designed to be used as a |
| 829 | base for new work; they are only there to make sure that topics in |
| 830 | flight work well together. This is why both <code>next</code> and <code>seen</code> are |
| 831 | frequently re-integrated with incoming patches on the mailing list and |
| 832 | force-pushed to replace previous versions of themselves. A topic that is |
| 833 | literally built on top of <code>next</code> cannot be merged to <code>master</code> without |
| 834 | dragging in all the other topics in <code>next</code>, some of which may not be |
| 835 | ready.</p></div> |
| 836 | <div class="paragraph"><p>For example, if you are making tree-wide changes, while somebody else is |
| 837 | also making their own tree-wide changes, your work may have severe |
| 838 | overlap with the other person’s work. This situation may tempt you to |
| 839 | use <code>next</code> as your starting point (because it would have the other |
| 840 | person’s work included in it), but doing so would mean you’ll not only |
| 841 | depend on the other person’s work, but all the other random things from |
| 842 | other contributors that are already integrated into <code>next</code>. And as soon |
| 843 | as <code>next</code> is updated with a new version, all of your work will need to |
| 844 | be rebased anyway in order for them to be cleanly applied by the |
| 845 | maintainer.</p></div> |
| 846 | <div class="paragraph"><p>Under truly exceptional circumstances where you absolutely must depend |
| 847 | on a select few topic branches that are already in <code>next</code> but not in |
| 848 | <code>master</code>, you may want to create your own custom base-branch by forking |
| 849 | <code>master</code> and merging the required topic branches to it. You could then |
| 850 | work on top of this base-branch. But keep in mind that this base-branch |
| 851 | would only be known privately to you. So when you are ready to send |
| 852 | your patches to the list, be sure to communicate how you created it in |
| 853 | your cover letter. This critical piece of information would allow |
| 854 | others to recreate your base-branch on their end in order for them to |
| 855 | try out your work.</p></div> |
| 856 | <div class="paragraph"><p>Finally, note that some parts of the system have dedicated maintainers |
| 857 | with their own separate source code repositories (see the section |
| 858 | "Subsystems" below).</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 859 | </div> |
| 860 | <div class="sect2"> |
| 861 | <h3 id="separate-commits">Make separate commits for logically separate changes.</h3> |
| 862 | <div class="paragraph"><p>Unless your patch is really trivial, you should not be sending |
| 863 | out a patch that was generated between your working tree and |
| 864 | your commit head. Instead, always make a commit with complete |
| 865 | commit message and generate a series of patches from your |
| 866 | repository. It is a good discipline.</p></div> |
| 867 | <div class="paragraph"><p>Give an explanation for the change(s) that is detailed enough so |
| 868 | that people can judge if it is good thing to do, without reading |
| 869 | the actual patch text to determine how well the code does what |
| 870 | the explanation promises to do.</p></div> |
| 871 | <div class="paragraph"><p>If your description starts to get too long, that’s a sign that you |
| 872 | probably need to split up your commit to finer grained pieces. |
| 873 | That being said, patches which plainly describe the things that |
| 874 | help reviewers check the patch, and future maintainers understand |
| 875 | the code, are the most beautiful patches. Descriptions that summarize |
| 876 | the point in the subject well, and describe the motivation for the |
| 877 | change, the approach taken by the change, and if relevant how this |
| 878 | differs substantially from the prior version, are all good things |
| 879 | to have.</p></div> |
| 880 | <div class="paragraph"><p>Make sure that you have tests for the bug you are fixing. See |
| 881 | <code>t/README</code> for guidance.</p></div> |
| 882 | <div class="paragraph" id="tests"><p>When adding a new feature, make sure that you have new tests to show |
| 883 | the feature triggers the new behavior when it should, and to show the |
| Junio C Hamano | 9d060b8 | 2022-01-10 21:34:48 | [diff] [blame] | 884 | feature does not trigger when it shouldn’t. After any code change, |
| 885 | make sure that the entire test suite passes. When fixing a bug, make |
| 886 | sure you have new tests that break if somebody else breaks what you |
| 887 | fixed by accident to avoid regression. Also, try merging your work to |
| 888 | <em>next</em> and <em>seen</em> and make sure the tests still pass; topics by others |
| 889 | that are still in flight may have unexpected interactions with what |
| 890 | you are trying to do in your topic.</p></div> |
| Junio C Hamano | 2e5fb40 | 2021-08-04 21:41:11 | [diff] [blame] | 891 | <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 |
| 892 | integration to test your changes on Linux, Mac and Windows. See the |
| 893 | <a href="#GHCI">GitHub CI</a> section for details.</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 894 | <div class="paragraph"><p>Do not forget to update the documentation to describe the updated |
| 895 | behavior and make sure that the resulting documentation set formats |
| Junio C Hamano | 980e61e | 2018-09-17 22:45:52 | [diff] [blame] | 896 | well (try the Documentation/doc-diff script).</p></div> |
| 897 | <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] | 898 | spelling and grammar, which is somewhat unfortunate. A huge patch that |
| 899 | touches the files all over the place only to correct the inconsistency |
| 900 | is not welcome, though. Potential clashes with other changes that can |
| 901 | result from such a patch are not worth it. We prefer to gradually |
| 902 | reconcile the inconsistencies in favor of US English, with small and |
| 903 | easily digestible patches, as a side effect of doing some other real |
| 904 | work in the vicinity (e.g. rewriting a paragraph for clarity, while |
| 905 | turning en_UK spelling to en_US). Obvious typographical fixes are much |
| 906 | more welcomed ("teh → "the"), preferably submitted as independent |
| 907 | patches separate from other documentation changes.</p></div> |
| 908 | <div class="paragraph" id="whitespace-check"><p>Oh, another thing. We are picky about whitespaces. Make sure your |
| 909 | changes do not trigger errors with the sample pre-commit hook shipped |
| 910 | in <code>templates/hooks--pre-commit</code>. To help ensure this does not happen, |
| 911 | run <code>git diff --check</code> on your changes before you commit.</p></div> |
| 912 | </div> |
| 913 | <div class="sect2"> |
| 914 | <h3 id="describe-changes">Describe your changes well.</h3> |
| Junio C Hamano | f1fc6ca | 2022-02-17 01:32:33 | [diff] [blame] | 915 | <div class="paragraph"><p>The log message that explains your changes is just as important as the |
| 916 | changes themselves. Your code may be clearly written with in-code |
| 917 | comment to sufficiently explain how it works with the surrounding |
| 918 | code, but those who need to fix or enhance your code in the future |
| 919 | will need to know <em>why</em> your code does what it does, for a few |
| 920 | reasons:</p></div> |
| 921 | <div class="olist arabic"><ol class="arabic"> |
| 922 | <li> |
| 923 | <p> |
| 924 | Your code may be doing something differently from what you wanted it |
| 925 | to do. Writing down what you actually wanted to achieve will help |
| 926 | them fix your code and make it do what it should have been doing |
| 927 | (also, you often discover your own bugs yourself, while writing the |
| 928 | log message to summarize the thought behind it). |
| 929 | </p> |
| 930 | </li> |
| 931 | <li> |
| 932 | <p> |
| 933 | Your code may be doing things that were only necessary for your |
| 934 | immediate needs (e.g. "do X to directories" without implementing or |
| 935 | even designing what is to be done on files). Writing down why you |
| 936 | excluded what the code does not do will help guide future developers. |
| 937 | Writing down "we do X to directories, because directories have |
| 938 | characteristic Y" would help them infer "oh, files also have the same |
| 939 | characteristic Y, so perhaps doing X to them would also make sense?". |
| 940 | Saying "we don’t do the same X to files, because …" will help them |
| 941 | decide if the reasoning is sound (in which case they do not waste |
| 942 | time extending your code to cover files), or reason differently (in |
| 943 | which case, they can explain why they extend your code to cover |
| 944 | files, too). |
| 945 | </p> |
| 946 | </li> |
| 947 | </ol></div> |
| 948 | <div class="paragraph"><p>The goal of your log message is to convey the <em>why</em> behind your |
| 949 | change to help future developers.</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 950 | <div class="paragraph"><p>The first line of the commit message should be a short description (50 |
| 951 | characters is the soft limit, see DISCUSSION in <a href="git-commit.html">git-commit(1)</a>), |
| 952 | and should skip the full stop. It is also conventional in most cases to |
| 953 | prefix the first line with "area: " where the area is a filename or |
| 954 | identifier for the general area of the code being modified, e.g.</p></div> |
| 955 | <div class="ulist"><ul> |
| 956 | <li> |
| 957 | <p> |
| 958 | doc: clarify distinction between sign-off and pgp-signing |
| 959 | </p> |
| 960 | </li> |
| 961 | <li> |
| 962 | <p> |
| 963 | githooks.txt: improve the intro section |
| 964 | </p> |
| 965 | </li> |
| 966 | </ul></div> |
| 967 | <div class="paragraph"><p>If in doubt which identifier to use, run <code>git log --no-merges</code> on the |
| 968 | files you are modifying to see the current conventions.</p></div> |
| Junio C Hamano | 4078a55 | 2021-04-30 06:08:10 | [diff] [blame] | 969 | <div class="paragraph" id="summary-section"><p>The title sentence after the "area:" prefix omits the full stop at the |
| Junio C Hamano | dac8a36 | 2022-10-17 22:25:51 | [diff] [blame] | 970 | end, and its first word is not capitalized (the omission |
| 971 | of capitalization applies only to the word after the "area:" |
| 972 | prefix of the title) unless there is a reason to |
| Junio C Hamano | 4078a55 | 2021-04-30 06:08:10 | [diff] [blame] | 973 | capitalize it other than because it is the first word in the sentence. |
| 974 | E.g. "doc: clarify…", not "doc: Clarify…", or "githooks.txt: |
| 975 | improve…", not "githooks.txt: Improve…". But "refs: HEAD is also |
| 976 | treated as a ref" is correct, as we spell <code>HEAD</code> in all caps even when |
| 977 | it appears in the middle of a sentence.</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 978 | <div class="paragraph" id="meaningful-message"><p>The body should provide a meaningful commit message, which:</p></div> |
| 979 | <div class="olist arabic"><ol class="arabic"> |
| 980 | <li> |
| 981 | <p> |
| 982 | explains the problem the change tries to solve, i.e. what is wrong |
| 983 | with the current code without the change. |
| 984 | </p> |
| 985 | </li> |
| 986 | <li> |
| 987 | <p> |
| 988 | justifies the way the change solves the problem, i.e. why the |
| 989 | result with the change is better. |
| 990 | </p> |
| 991 | </li> |
| 992 | <li> |
| 993 | <p> |
| 994 | alternate solutions considered but discarded, if any. |
| 995 | </p> |
| 996 | </li> |
| 997 | </ol></div> |
| Junio C Hamano | f1fc6ca | 2022-02-17 01:32:33 | [diff] [blame] | 998 | <div class="paragraph" id="present-tense"><p>The problem statement that describes the status quo is written in the |
| 999 | present tense. Write "The code does X when it is given input Y", |
| 1000 | instead of "The code used to do Y when given input X". You do not |
| 1001 | have to say "Currently"---the status quo in the problem statement is |
| 1002 | about the code <em>without</em> your change, by project convention.</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1003 | <div class="paragraph" id="imperative-mood"><p>Describe your changes in imperative mood, e.g. "make xyzzy do frotz" |
| 1004 | instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy |
| 1005 | to do frotz", as if you are giving orders to the codebase to change |
| 1006 | its behavior. Try to make sure your explanation can be understood |
| 1007 | without external resources. Instead of giving a URL to a mailing list |
| 1008 | archive, summarize the relevant points of the discussion.</p></div> |
| Junio C Hamano | 9d060b8 | 2022-01-10 21:34:48 | [diff] [blame] | 1009 | <div class="paragraph" id="commit-reference"><p>There are a few reasons why you may want to refer to another commit in |
| 1010 | the "more stable" part of the history (i.e. on branches like <code>maint</code>, |
| 1011 | <code>master</code>, and <code>next</code>):</p></div> |
| 1012 | <div class="olist arabic"><ol class="arabic"> |
| 1013 | <li> |
| 1014 | <p> |
| 1015 | A commit that introduced the root cause of a bug you are fixing. |
| 1016 | </p> |
| 1017 | </li> |
| 1018 | <li> |
| 1019 | <p> |
| 1020 | A commit that introduced a feature that you are enhancing. |
| 1021 | </p> |
| 1022 | </li> |
| 1023 | <li> |
| 1024 | <p> |
| 1025 | A commit that conflicts with your work when you made a trial merge |
| 1026 | of your work into <code>next</code> and <code>seen</code> for testing. |
| 1027 | </p> |
| 1028 | </li> |
| 1029 | </ol></div> |
| 1030 | <div class="paragraph"><p>When you reference a commit on a more stable branch (like <code>master</code>, |
| 1031 | <code>maint</code> and <code>next</code>), use the format "abbreviated hash (subject, |
| 1032 | date)", like this:</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1033 | <div class="literalblock"> |
| 1034 | <div class="content"> |
| Junio C Hamano | b489685 | 2019-12-10 23:15:09 | [diff] [blame] | 1035 | <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] | 1036 | noticed that ...</code></pre> |
| 1037 | </div></div> |
| 1038 | <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] | 1039 | format (with the subject enclosed in a pair of double-quotes), or this |
| 1040 | invocation of <code>git show</code>:</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1041 | <div class="literalblock"> |
| 1042 | <div class="content"> |
| Junio C Hamano | b489685 | 2019-12-10 23:15:09 | [diff] [blame] | 1043 | <pre><code> git show -s --pretty=reference <commit></code></pre> |
| 1044 | </div></div> |
| 1045 | <div class="paragraph"><p>or, on an older version of Git without support for --pretty=reference:</p></div> |
| 1046 | <div class="literalblock"> |
| 1047 | <div class="content"> |
| 1048 | <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] | 1049 | </div></div> |
| 1050 | </div> |
| 1051 | <div class="sect2"> |
| Junio C Hamano | 2e5fb40 | 2021-08-04 21:41:11 | [diff] [blame] | 1052 | <h3 id="sign-off">Certify your work by adding your <code>Signed-off-by</code> trailer</h3> |
| 1053 | <div class="paragraph"><p>To improve tracking of who did what, we ask you to certify that you |
| 1054 | wrote the patch or have the right to pass it on under the same license |
| 1055 | as ours, by "signing off" your patch. Without sign-off, we cannot |
| 1056 | accept your patches.</p></div> |
| 1057 | <div class="paragraph"><p>If (and only if) you certify the below D-C-O:</p></div> |
| 1058 | <div class="quoteblock" id="dco"> |
| 1059 | <div class="title">Developer’s Certificate of Origin 1.1</div> |
| 1060 | <div class="content"> |
| 1061 | <div class="paragraph"><p>By making a contribution to this project, I certify that:</p></div> |
| 1062 | <div class="olist loweralpha"><ol class="loweralpha"> |
| 1063 | <li> |
| 1064 | <p> |
| 1065 | The contribution was created in whole or in part by me and I |
| 1066 | have the right to submit it under the open source license |
| 1067 | indicated in the file; or |
| 1068 | </p> |
| 1069 | </li> |
| 1070 | <li> |
| 1071 | <p> |
| 1072 | The contribution is based upon previous work that, to the best |
| 1073 | of my knowledge, is covered under an appropriate open source |
| 1074 | license and I have the right under that license to submit that |
| 1075 | work with modifications, whether created in whole or in part |
| 1076 | by me, under the same open source license (unless I am |
| 1077 | permitted to submit under a different license), as indicated |
| 1078 | in the file; or |
| 1079 | </p> |
| 1080 | </li> |
| 1081 | <li> |
| 1082 | <p> |
| 1083 | The contribution was provided directly to me by some other |
| 1084 | person who certified (a), (b) or (c) and I have not modified |
| 1085 | it. |
| 1086 | </p> |
| 1087 | </li> |
| 1088 | <li> |
| 1089 | <p> |
| 1090 | I understand and agree that this project and the contribution |
| 1091 | are public and that a record of the contribution (including all |
| 1092 | personal information I submit with it, including my sign-off) is |
| 1093 | maintained indefinitely and may be redistributed consistent with |
| 1094 | this project or the open source license(s) involved. |
| 1095 | </p> |
| 1096 | </li> |
| 1097 | </ol></div> |
| 1098 | </div> |
| 1099 | <div class="attribution"> |
| 1100 | </div></div> |
| 1101 | <div class="paragraph"><p>you add a "Signed-off-by" trailer to your commit, that looks like |
| 1102 | this:</p></div> |
| 1103 | <div class="literalblock"> |
| 1104 | <div class="content"> |
| 1105 | <pre><code> Signed-off-by: Random J Developer <random@developer.example.org></code></pre> |
| 1106 | </div></div> |
| 1107 | <div class="paragraph"><p>This line can be added by Git if you run the git-commit command with |
| 1108 | the -s option.</p></div> |
| 1109 | <div class="paragraph"><p>Notice that you can place your own <code>Signed-off-by</code> trailer when |
| 1110 | forwarding somebody else’s patch with the above rules for |
| 1111 | D-C-O. Indeed you are encouraged to do so. Do not forget to |
| 1112 | place an in-body "From: " line at the beginning to properly attribute |
| 1113 | the change to its true author (see (2) above).</p></div> |
| 1114 | <div class="paragraph"><p>This procedure originally came from the Linux kernel project, so our |
| 1115 | rule is quite similar to theirs, but what exactly it means to sign-off |
| 1116 | your patch differs from project to project, so it may be different |
| 1117 | from that of the project you are accustomed to.</p></div> |
| 1118 | <div class="paragraph" id="real-name"><p>Also notice that a real name is used in the <code>Signed-off-by</code> trailer. Please |
| 1119 | don’t hide your real name.</p></div> |
| 1120 | <div class="paragraph" id="commit-trailers"><p>If you like, you can put extra tags at the end:</p></div> |
| 1121 | <div class="olist arabic"><ol class="arabic"> |
| 1122 | <li> |
| 1123 | <p> |
| 1124 | <code>Reported-by:</code> is used to credit someone who found the bug that |
| 1125 | the patch attempts to fix. |
| 1126 | </p> |
| 1127 | </li> |
| 1128 | <li> |
| 1129 | <p> |
| 1130 | <code>Acked-by:</code> says that the person who is more familiar with the area |
| 1131 | the patch attempts to modify liked the patch. |
| 1132 | </p> |
| 1133 | </li> |
| 1134 | <li> |
| 1135 | <p> |
| 1136 | <code>Reviewed-by:</code>, unlike the other tags, can only be offered by the |
| 1137 | reviewers themselves when they are completely satisfied with the |
| 1138 | patch after a detailed analysis. |
| 1139 | </p> |
| 1140 | </li> |
| 1141 | <li> |
| 1142 | <p> |
| 1143 | <code>Tested-by:</code> is used to indicate that the person applied the patch |
| 1144 | and found it to have the desired effect. |
| 1145 | </p> |
| 1146 | </li> |
| 1147 | </ol></div> |
| 1148 | <div class="paragraph"><p>You can also create your own tag or use one that’s in common usage |
| 1149 | such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".</p></div> |
| 1150 | </div> |
| 1151 | <div class="sect2"> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1152 | <h3 id="git-tools">Generate your patch using Git tools out of your commits.</h3> |
| 1153 | <div class="paragraph"><p>Git based diff tools generate unidiff which is the preferred format.</p></div> |
| 1154 | <div class="paragraph"><p>You do not have to be afraid to use <code>-M</code> option to <code>git diff</code> or |
| 1155 | <code>git format-patch</code>, if your patch involves file renames. The |
| 1156 | receiving end can handle them just fine.</p></div> |
| 1157 | <div class="paragraph" id="review-patch"><p>Please make sure your patch does not add commented out debugging code, |
| 1158 | or include any extra files which do not relate to what your patch |
| 1159 | is trying to achieve. Make sure to review |
| 1160 | your patch after generating it, to ensure accuracy. Before |
| Junio C Hamano | 62908fd | 2023-08-04 19:05:22 | [diff] [blame] | 1161 | sending out, please make sure it cleanly applies to the starting point you |
| 1162 | have chosen in the "Choose a starting point" section.</p></div> |
| 1163 | <div class="admonitionblock"> |
| 1164 | <table><tr> |
| 1165 | <td class="icon"> |
| 1166 | <div class="title">Note</div> |
| 1167 | </td> |
| 1168 | <td class="content">From the perspective of those reviewing your patch, the <code>master</code> |
| 1169 | branch is the default expected starting point. So if you have chosen a |
| 1170 | different starting point, please communicate this choice in your cover |
| 1171 | letter.</td> |
| 1172 | </tr></table> |
| 1173 | </div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1174 | </div> |
| 1175 | <div class="sect2"> |
| 1176 | <h3 id="send-patches">Sending your patches.</h3> |
| Junio C Hamano | 4dca903 | 2018-06-04 13:49:31 | [diff] [blame] | 1177 | <div class="paragraph"><p>Before sending any patches, please note that patches that may be |
| 1178 | security relevant should be submitted privately to the Git Security |
| 1179 | 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] | 1180 | <div class="paragraph"><p>Learn to use format-patch and send-email if possible. These commands |
| 1181 | are optimized for the workflow of sending patches, avoiding many ways |
| 1182 | your existing e-mail client that is optimized for "multipart/*" mime |
| 1183 | type e-mails to corrupt and render your patches unusable.</p></div> |
| 1184 | <div class="paragraph"><p>People on the Git mailing list need to be able to read and |
| 1185 | comment on the changes you are submitting. It is important for |
| 1186 | a developer to be able to "quote" your changes, using standard |
| 1187 | e-mail tools, so that they may comment on specific portions of |
| 1188 | your code. For this reason, each patch should be submitted |
| 1189 | "inline" in a separate message.</p></div> |
| 1190 | <div class="paragraph"><p>Multiple related patches should be grouped into their own e-mail |
| 1191 | thread to help readers find all parts of the series. To that end, |
| 1192 | send them as replies to either an additional "cover letter" message |
| 1193 | (see below), the first patch, or the respective preceding patch.</p></div> |
| 1194 | <div class="paragraph"><p>If your log message (including your name on the |
| Junio C Hamano | df3d3cd | 2020-11-02 22:05:05 | [diff] [blame] | 1195 | <code>Signed-off-by</code> trailer) is not writable in ASCII, make sure that |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1196 | you send off a message in the correct encoding.</p></div> |
| 1197 | <div class="admonitionblock"> |
| 1198 | <table><tr> |
| 1199 | <td class="icon"> |
| 1200 | <div class="title">Warning</div> |
| 1201 | </td> |
| 1202 | <td class="content">Be wary of your MUAs word-wrap |
| 1203 | corrupting your patch. Do not cut-n-paste your patch; you can |
| 1204 | lose tabs that way if you are not careful.</td> |
| 1205 | </tr></table> |
| 1206 | </div> |
| 1207 | <div class="paragraph"><p>It is a common convention to prefix your subject line with |
| 1208 | [PATCH]. This lets people easily distinguish patches from other |
| Junio C Hamano | d710560 | 2017-11-21 05:32:50 | [diff] [blame] | 1209 | e-mail discussions. Use of markers in addition to PATCH within |
| 1210 | the brackets to describe the nature of the patch is also |
| 1211 | encouraged. E.g. [RFC PATCH] (where RFC stands for "request for |
| 1212 | comments") is often used to indicate a patch needs further |
| 1213 | discussion before being accepted, [PATCH v2], [PATCH v3] etc. |
| 1214 | are often seen when you are sending an update to what you have |
| 1215 | previously sent.</p></div> |
| 1216 | <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] | 1217 | format the body of an e-mail message. At the beginning of the |
| 1218 | patch should come your commit message, ending with the |
| Junio C Hamano | df3d3cd | 2020-11-02 22:05:05 | [diff] [blame] | 1219 | <code>Signed-off-by</code> trailers, and a line that consists of three dashes, |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1220 | followed by the diffstat information and the patch itself. If |
| 1221 | you are forwarding a patch from somebody else, optionally, at |
| 1222 | the beginning of the e-mail message just before the commit |
| Junio C Hamano | d710560 | 2017-11-21 05:32:50 | [diff] [blame] | 1223 | message starts, you can put a "From: " line to name that person. |
| 1224 | To change the default "[PATCH]" in the subject to "[<text>]", use |
| 1225 | <code>git format-patch --subject-prefix=<text></code>. As a shortcut, you |
| 1226 | can use <code>--rfc</code> instead of <code>--subject-prefix="RFC PATCH"</code>, or |
| 1227 | <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] | 1228 | <div class="paragraph"><p>You often want to add additional explanation about the patch, |
| 1229 | other than the commit message itself. Place such "cover letter" |
| 1230 | material between the three-dash line and the diffstat. For |
| 1231 | patches requiring multiple iterations of review and discussion, |
| 1232 | an explanation of changes between each iteration can be kept in |
| 1233 | Git-notes and inserted automatically following the three-dash |
| 1234 | line via <code>git format-patch --notes</code>.</p></div> |
| 1235 | <div class="paragraph" id="attachment"><p>Do not attach the patch as a MIME attachment, compressed or not. |
| 1236 | Do not let your e-mail client send quoted-printable. Do not let |
| 1237 | your e-mail client send format=flowed which would destroy |
| 1238 | whitespaces in your patches. Many |
| 1239 | popular e-mail applications will not always transmit a MIME |
| 1240 | attachment as plain text, making it impossible to comment on |
| 1241 | your code. A MIME attachment also takes a bit more time to |
| 1242 | process. This does not decrease the likelihood of your |
| 1243 | MIME-attached change being accepted, but it makes it more likely |
| 1244 | that it will be postponed.</p></div> |
| 1245 | <div class="paragraph"><p>Exception: If your mailer is mangling patches then someone may ask |
| 1246 | you to re-send them using MIME, that is OK.</p></div> |
| 1247 | <div class="paragraph" id="pgp-signature"><p>Do not PGP sign your patch. Most likely, your maintainer or other people on the |
| 1248 | list would not have your PGP key and would not bother obtaining it anyway. |
| 1249 | Your patch is not judged by who you are; a good patch from an unknown origin |
| 1250 | has a far better chance of being accepted than a patch from a known, respected |
| 1251 | origin that is done poorly or does incorrect things.</p></div> |
| 1252 | <div class="paragraph"><p>If you really really really really want to do a PGP signed |
| 1253 | patch, format it as "multipart/signed", not a text/plain message |
| 1254 | that starts with <code>-----BEGIN PGP SIGNED MESSAGE-----</code>. That is |
| 1255 | not a text/plain, it’s something else.</p></div> |
| Junio C Hamano | 4dca903 | 2018-06-04 13:49:31 | [diff] [blame] | 1256 | <div class="paragraph"><p>As mentioned at the beginning of the section, patches that may be |
| 1257 | security relevant should not be submitted to the public mailing list |
| 1258 | mentioned below, but should instead be sent privately to the Git |
| 1259 | 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] | 1260 | <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] | 1261 | people who are involved in the area you are touching (the <code>git |
| 1262 | contacts</code> command in <code>contrib/contacts/</code> can help to |
| Junio C Hamano | 9d060b8 | 2022-01-10 21:34:48 | [diff] [blame] | 1263 | identify them), to solicit comments and reviews. Also, when you made |
| 1264 | trial merges of your topic to <code>next</code> and <code>seen</code>, you may have noticed |
| 1265 | work by others conflicting with your changes. There is a good possibility |
| 1266 | that these people may know the area you are touching well.</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1267 | <div class="paragraph"><p>After the list reached a consensus that it is a good idea to apply the |
| Junio C Hamano | df3d3cd | 2020-11-02 22:05:05 | [diff] [blame] | 1268 | 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> |
| 1269 | 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 |
| 1270 | when the maintainer did not heavily participate in the discussion and |
| 1271 | instead left the review to trusted others.</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1272 | <div class="paragraph"><p>Do not forget to add trailers such as <code>Acked-by:</code>, <code>Reviewed-by:</code> and |
| 1273 | <code>Tested-by:</code> lines as necessary to credit people who helped your |
| Junio C Hamano | df3d3cd | 2020-11-02 22:05:05 | [diff] [blame] | 1274 | patch, and "cc:" them when sending such a final version for inclusion.</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1275 | </div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1276 | </div> |
| 1277 | </div> |
| 1278 | <div class="sect1"> |
| 1279 | <h2 id="_subsystems_with_dedicated_maintainers">Subsystems with dedicated maintainers</h2> |
| 1280 | <div class="sectionbody"> |
| 1281 | <div class="paragraph"><p>Some parts of the system have dedicated maintainers with their own |
| 1282 | repositories.</p></div> |
| 1283 | <div class="ulist"><ul> |
| 1284 | <li> |
| 1285 | <p> |
| Junio C Hamano | 48cd3f1 | 2019-10-09 05:55:30 | [diff] [blame] | 1286 | <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] | 1287 | </p> |
| 1288 | <div class="literalblock"> |
| 1289 | <div class="content"> |
| Junio C Hamano | 48cd3f1 | 2019-10-09 05:55:30 | [diff] [blame] | 1290 | <pre><code>https://github.com/prati0100/git-gui.git</code></pre> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1291 | </div></div> |
| 1292 | </li> |
| 1293 | <li> |
| 1294 | <p> |
| Junio C Hamano | b551377 | 2019-04-22 03:38:39 | [diff] [blame] | 1295 | <code>gitk-git/</code> comes from Paul Mackerras’s gitk project: |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1296 | </p> |
| 1297 | <div class="literalblock"> |
| 1298 | <div class="content"> |
| Junio C Hamano | 72ea2ca | 2022-05-21 00:51:23 | [diff] [blame] | 1299 | <pre><code>git://git.ozlabs.org/~paulus/gitk</code></pre> |
| 1300 | </div></div> |
| 1301 | <div class="literalblock"> |
| 1302 | <div class="content"> |
| 1303 | <pre><code>Those who are interested in improve gitk can volunteer to help Paul |
| 1304 | in maintaining it cf. <YntxL/fTplFm8lr6@cleo>.</code></pre> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1305 | </div></div> |
| 1306 | </li> |
| 1307 | <li> |
| 1308 | <p> |
| Junio C Hamano | b551377 | 2019-04-22 03:38:39 | [diff] [blame] | 1309 | <code>po/</code> comes from the localization coordinator, Jiang Xin: |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1310 | </p> |
| 1311 | <div class="literalblock"> |
| 1312 | <div class="content"> |
| 1313 | <pre><code>https://github.com/git-l10n/git-po/</code></pre> |
| 1314 | </div></div> |
| 1315 | </li> |
| 1316 | </ul></div> |
| 1317 | <div class="paragraph"><p>Patches to these parts should be based on their trees.</p></div> |
| 1318 | </div> |
| 1319 | </div> |
| 1320 | <div class="sect1"> |
| 1321 | <h2 id="patch-flow">An ideal patch flow</h2> |
| 1322 | <div class="sectionbody"> |
| 1323 | <div class="paragraph"><p>Here is an ideal patch flow for this project the current maintainer |
| 1324 | suggests to the contributors:</p></div> |
| 1325 | <div class="olist arabic"><ol class="arabic"> |
| 1326 | <li> |
| 1327 | <p> |
| 1328 | You come up with an itch. You code it up. |
| 1329 | </p> |
| 1330 | </li> |
| 1331 | <li> |
| 1332 | <p> |
| 1333 | Send it to the list and cc people who may need to know about |
| 1334 | the change. |
| 1335 | </p> |
| 1336 | <div class="paragraph"><p>The people who may need to know are the ones whose code you |
| 1337 | are butchering. These people happen to be the ones who are |
| 1338 | most likely to be knowledgeable enough to help you, but |
| 1339 | they have no obligation to help you (i.e. you ask for help, |
| 1340 | don’t demand). <code>git log -p -- <em>$area_you_are_modifying</em></code> would |
| 1341 | help you find out who they are.</p></div> |
| 1342 | </li> |
| 1343 | <li> |
| 1344 | <p> |
| 1345 | You get comments and suggestions for improvements. You may |
| Junio C Hamano | ea1ac8d | 2018-07-18 20:16:48 | [diff] [blame] | 1346 | even get them in an "on top of your change" patch form. |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1347 | </p> |
| 1348 | </li> |
| 1349 | <li> |
| 1350 | <p> |
| 1351 | Polish, refine, and re-send to the list and the people who |
| 1352 | spend their time to improve your patch. Go back to step (2). |
| 1353 | </p> |
| 1354 | </li> |
| 1355 | <li> |
| 1356 | <p> |
| 1357 | The list forms consensus that the last round of your patch is |
| 1358 | good. Send it to the maintainer and cc the list. |
| 1359 | </p> |
| 1360 | </li> |
| 1361 | <li> |
| 1362 | <p> |
| 1363 | A topic branch is created with the patch and is merged to <code>next</code>, |
| 1364 | and cooked further and eventually graduates to <code>master</code>. |
| 1365 | </p> |
| 1366 | </li> |
| 1367 | </ol></div> |
| 1368 | <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] | 1369 | 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] | 1370 | people play with it without having to pick up and apply the patch to |
| 1371 | their trees themselves.</p></div> |
| 1372 | </div> |
| 1373 | </div> |
| 1374 | <div class="sect1"> |
| 1375 | <h2 id="patch-status">Know the status of your patch after submission</h2> |
| 1376 | <div class="sectionbody"> |
| 1377 | <div class="ulist"><ul> |
| 1378 | <li> |
| 1379 | <p> |
| 1380 | You can use Git itself to find out when your patch is merged in |
| 1381 | master. <code>git pull --rebase</code> will automatically skip already-applied |
| 1382 | patches, and will let you know. This works only if you rebase on top |
| 1383 | 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] | 1384 | 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] | 1385 | master). |
| 1386 | </p> |
| 1387 | </li> |
| 1388 | <li> |
| 1389 | <p> |
| 1390 | Read the Git mailing list, the maintainer regularly posts messages |
| 1391 | entitled "What’s cooking in git.git" and "What’s in git.git" giving |
| 1392 | the status of various proposed changes. |
| 1393 | </p> |
| 1394 | </li> |
| 1395 | </ul></div> |
| 1396 | </div> |
| 1397 | </div> |
| 1398 | <div class="sect1"> |
| Junio C Hamano | 7654558 | 2021-11-22 16:53:52 | [diff] [blame] | 1399 | <h2 id="_github_ci_a_id_ghci_a">GitHub CI<a id="GHCI"></a></h2> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1400 | <div class="sectionbody"> |
| Junio C Hamano | 2e5fb40 | 2021-08-04 21:41:11 | [diff] [blame] | 1401 | <div class="paragraph"><p>With an account at GitHub, you can use GitHub CI to test your changes |
| 1402 | on Linux, Mac and Windows. See |
| 1403 | <a href="https://github.com/git/git/actions/workflows/main.yml">https://github.com/git/git/actions/workflows/main.yml</a> for examples of |
| 1404 | recent CI runs.</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1405 | <div class="paragraph"><p>Follow these steps for the initial setup:</p></div> |
| 1406 | <div class="olist arabic"><ol class="arabic"> |
| 1407 | <li> |
| 1408 | <p> |
| 1409 | Fork <a href="https://github.com/git/git">https://github.com/git/git</a> to your GitHub account. |
| 1410 | You can find detailed instructions how to fork here: |
| 1411 | <a href="https://help.github.com/articles/fork-a-repo/">https://help.github.com/articles/fork-a-repo/</a> |
| 1412 | </p> |
| 1413 | </li> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1414 | </ol></div> |
| Junio C Hamano | 2e5fb40 | 2021-08-04 21:41:11 | [diff] [blame] | 1415 | <div class="paragraph"><p>After the initial setup, CI will run whenever you push new changes |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1416 | to your fork of Git on GitHub. You can monitor the test state of all your |
| Junio C Hamano | 7654558 | 2021-11-22 16:53:52 | [diff] [blame] | 1417 | branches here: <code>https://github.com/<Your GitHub handle>/git/actions/workflows/main.yml</code></p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1418 | <div class="paragraph"><p>If a branch did not pass all test cases then it is marked with a red |
| Junio C Hamano | 2e5fb40 | 2021-08-04 21:41:11 | [diff] [blame] | 1419 | cross. In that case you can click on the failing job and navigate to |
| 1420 | "ci/run-build-and-tests.sh" and/or "ci/print-test-failures.sh". You |
| 1421 | can also download "Artifacts" which are tarred (or zipped) archives |
| 1422 | with test data relevant for debugging.</p></div> |
| 1423 | <div class="paragraph"><p>Then fix the problem and push your fix to your GitHub fork. This will |
| 1424 | trigger a new CI build to ensure all tests pass.</p></div> |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1425 | </div> |
| 1426 | </div> |
| 1427 | <div class="sect1"> |
| 1428 | <h2 id="mua">MUA specific hints</h2> |
| 1429 | <div class="sectionbody"> |
| Junio C Hamano | 3a9663e | 2023-04-11 20:54:14 | [diff] [blame] | 1430 | <div class="paragraph"><p>Some of the patches I receive or pick up from the list share common |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1431 | patterns of breakage. Please make sure your MUA is set up |
| 1432 | properly not to corrupt whitespaces.</p></div> |
| 1433 | <div class="paragraph"><p>See the DISCUSSION section of <a href="git-format-patch.html">git-format-patch(1)</a> for hints on |
| 1434 | checking your patch by mailing it to yourself and applying with |
| 1435 | <a href="git-am.html">git-am(1)</a>.</p></div> |
| 1436 | <div class="paragraph"><p>While you are at it, check the resulting commit log message from |
| 1437 | a trial run of applying the patch. If what is in the resulting |
| 1438 | commit is not exactly what you would want to see, it is very |
| 1439 | likely that your maintainer would end up hand editing the log |
| 1440 | message when he applies your patch. Things like "Hi, this is my |
| 1441 | first patch.\n", if you really want to put in the patch e-mail, |
| 1442 | should come after the three-dash line that signals the end of the |
| 1443 | commit message.</p></div> |
| 1444 | <div class="sect2"> |
| 1445 | <h3 id="_pine">Pine</h3> |
| 1446 | <div class="paragraph"><p>(Johannes Schindelin)</p></div> |
| 1447 | <div class="literalblock"> |
| 1448 | <div class="content"> |
| 1449 | <pre><code>I don't know how many people still use pine, but for those poor |
| 1450 | souls it may be good to mention that the quell-flowed-text is |
| 1451 | needed for recent versions. |
| 1452 | |
| 1453 | ... the "no-strip-whitespace-before-send" option, too. AFAIK it |
| 1454 | was introduced in 4.60.</code></pre> |
| 1455 | </div></div> |
| 1456 | <div class="paragraph"><p>(Linus Torvalds)</p></div> |
| 1457 | <div class="literalblock"> |
| 1458 | <div class="content"> |
| 1459 | <pre><code>And 4.58 needs at least this. |
| 1460 | |
| 1461 | diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1) |
| 1462 | Author: Linus Torvalds <torvalds@g5.osdl.org> |
| 1463 | Date: Mon Aug 15 17:23:51 2005 -0700 |
| 1464 | |
| 1465 | Fix pine whitespace-corruption bug |
| 1466 | |
| 1467 | There's no excuse for unconditionally removing whitespace from |
| 1468 | the pico buffers on close. |
| 1469 | |
| 1470 | diff --git a/pico/pico.c b/pico/pico.c |
| 1471 | --- a/pico/pico.c |
| 1472 | +++ b/pico/pico.c |
| 1473 | @@ -219,7 +219,9 @@ PICO *pm; |
| 1474 | switch(pico_all_done){ /* prepare for/handle final events */ |
| 1475 | case COMP_EXIT : /* already confirmed */ |
| 1476 | packheader(); |
| 1477 | +#if 0 |
| 1478 | stripwhitespace(); |
| 1479 | +#endif |
| 1480 | c |= COMP_EXIT; |
| 1481 | break;</code></pre> |
| 1482 | </div></div> |
| 1483 | <div class="paragraph"><p>(Daniel Barkalow)</p></div> |
| 1484 | <div class="literalblock"> |
| 1485 | <div class="content"> |
| 1486 | <pre><code>> A patch to SubmittingPatches, MUA specific help section for |
| 1487 | > users of Pine 4.63 would be very much appreciated. |
| 1488 | |
| 1489 | Ah, it looks like a recent version changed the default behavior to do the |
| 1490 | right thing, and inverted the sense of the configuration option. (Either |
| 1491 | that or Gentoo did it.) So you need to set the |
| 1492 | "no-strip-whitespace-before-send" option, unless the option you have is |
| 1493 | "strip-whitespace-before-send", in which case you should avoid checking |
| 1494 | it.</code></pre> |
| 1495 | </div></div> |
| 1496 | </div> |
| 1497 | <div class="sect2"> |
| 1498 | <h3 id="_thunderbird_kmail_gmail">Thunderbird, KMail, GMail</h3> |
| 1499 | <div class="paragraph"><p>See the MUA-SPECIFIC HINTS section of <a href="git-format-patch.html">git-format-patch(1)</a>.</p></div> |
| 1500 | </div> |
| 1501 | <div class="sect2"> |
| 1502 | <h3 id="_gnus">Gnus</h3> |
| 1503 | <div class="paragraph"><p>"|" in the <code>*Summary*</code> buffer can be used to pipe the current |
| 1504 | message to an external program, and this is a handy way to drive |
| 1505 | <code>git am</code>. However, if the message is MIME encoded, what is |
| 1506 | piped into the program is the representation you see in your |
| 1507 | <code>*Article*</code> buffer after unwrapping MIME. This is often not what |
| 1508 | you would want for two reasons. It tends to screw up non ASCII |
| 1509 | characters (most notably in people’s names), and also |
| 1510 | whitespaces (fatal in patches). Running "C-u g" to display the |
| 1511 | message in raw form before using "|" to run the pipe can work |
| 1512 | this problem around.</p></div> |
| 1513 | </div> |
| 1514 | </div> |
| 1515 | </div> |
| 1516 | </div> |
| 1517 | <div id="footnotes"><hr /></div> |
| 1518 | <div id="footer"> |
| 1519 | <div id="footer-text"> |
| Junio C Hamano | 2ef0ba3 | 2018-01-26 23:13:53 | [diff] [blame] | 1520 | Last updated |
| Junio C Hamano | 8a38ce8 | 2023-08-21 17:27:26 | [diff] [blame] | 1521 | 2023-08-21 10:25:10 PDT |
| Junio C Hamano | b72f603 | 2017-11-15 05:57:08 | [diff] [blame] | 1522 | </div> |
| 1523 | </div> |
| 1524 | </body> |
| 1525 | </html> |
