|
735 | 735 | <body class="article">
|
736 | 736 | <div id="header">
|
737 | 737 | <h1>Submitting Patches</h1>
|
738 |
| -<span id="revdate">2024-05-23</span> |
| 738 | +<span id="revdate">2024-05-28</span> |
739 | 739 | </div>
|
740 | 740 | <div id="content">
|
741 | 741 | <div class="sect1">
|
@@ -1422,6 +1422,111 @@ <h4 id="_code_format_patch_code_and_code_send_email_code"><code>format-patch</co
|
1422 | 1422 | not a text/plain, it’s something else.</p></div>
|
1423 | 1423 | </div>
|
1424 | 1424 | </div>
|
| 1425 | +<div class="sect2"> |
| 1426 | +<h3 id="_handling_conflicts_and_iterating_patches">Handling Conflicts and Iterating Patches</h3> |
| 1427 | +<div class="paragraph"><p>When revising changes made to your patches, it’s important to |
| 1428 | +acknowledge the possibility of conflicts with other ongoing topics. To |
| 1429 | +navigate these potential conflicts effectively, follow the recommended |
| 1430 | +steps outlined below:</p></div> |
| 1431 | +<div class="olist arabic"><ol class="arabic"> |
| 1432 | +<li> |
| 1433 | +<p> |
| 1434 | +Build on a suitable base branch, see the <a href="#choose-starting-point">section above</a>, |
| 1435 | +and format-patch the series. If you are doing "rebase -i" in-place to |
| 1436 | +update from the previous round, this will reuse the previous base so |
| 1437 | +(2) and (3) may become trivial. |
| 1438 | +</p> |
| 1439 | +</li> |
| 1440 | +<li> |
| 1441 | +<p> |
| 1442 | +Find the base of where the last round was queued |
| 1443 | +</p> |
| 1444 | +<div class="literalblock"> |
| 1445 | +<div class="content"> |
| 1446 | +<pre><code>$ mine='kn/ref-transaction-symref' |
| 1447 | +$ git checkout "origin/seen^{/^Merge branch '$mine'}...master"</code></pre> |
| 1448 | +</div></div> |
| 1449 | +</li> |
| 1450 | +<li> |
| 1451 | +<p> |
| 1452 | +Apply your format-patch result. There are two cases |
| 1453 | +</p> |
| 1454 | +<div class="olist loweralpha"><ol class="loweralpha"> |
| 1455 | +<li> |
| 1456 | +<p> |
| 1457 | +Things apply cleanly and tests fine. Go to (4). |
| 1458 | +</p> |
| 1459 | +</li> |
| 1460 | +<li> |
| 1461 | +<p> |
| 1462 | +Things apply cleanly but does not build or test fails, or things do |
| 1463 | +not apply cleanly. |
| 1464 | +</p> |
| 1465 | +<div class="paragraph"><p>In the latter case, you have textual or semantic conflicts coming from |
| 1466 | +the difference between the old base and the base you used to build in |
| 1467 | +(1). Identify what caused the breakages (e.g., a topic or two may have |
| 1468 | +merged since the base used by (2) until the base used by (1)).</p></div> |
| 1469 | +<div class="paragraph"><p>Check out the latest <em>origin/master</em> (which may be newer than the base |
| 1470 | +used by (2)), "merge --no-ff" the topics you newly depend on in there, |
| 1471 | +and use the result of the merge(s) as the base, rebuild the series and |
| 1472 | +test again. Run format-patch from the last such merges to the tip of |
| 1473 | +your topic. If you did</p></div> |
| 1474 | +<div class="literalblock"> |
| 1475 | +<div class="content"> |
| 1476 | +<pre><code>$ git checkout origin/master |
| 1477 | +$ git merge --no-ff --into-name kn/ref-transaction-symref fo/obar |
| 1478 | +$ git merge --no-ff --into-name kn/ref-transaction-symref ba/zqux |
| 1479 | +... rebuild the topic ...</code></pre> |
| 1480 | +</div></div> |
| 1481 | +<div class="paragraph"><p>Then you’d just format your topic above these "preparing the ground" |
| 1482 | +merges, e.g.</p></div> |
| 1483 | +<div class="literalblock"> |
| 1484 | +<div class="content"> |
| 1485 | +<pre><code>$ git format-patch "HEAD^{/^Merge branch 'ba/zqux'}"..HEAD</code></pre> |
| 1486 | +</div></div> |
| 1487 | +<div class="paragraph"><p>Do not forget to write in the cover letter you did this, including the |
| 1488 | +topics you have in your base on top of <em>master</em>. Then go to (4).</p></div> |
| 1489 | +</li> |
| 1490 | +</ol></div> |
| 1491 | +</li> |
| 1492 | +<li> |
| 1493 | +<p> |
| 1494 | +Make a trial merge of your topic into <em>next</em> and <em>seen</em>, e.g. |
| 1495 | +</p> |
| 1496 | +<div class="literalblock"> |
| 1497 | +<div class="content"> |
| 1498 | +<pre><code>$ git checkout --detach 'origin/seen' |
| 1499 | +$ git revert -m 1 <the merge of the previous iteration into seen> |
| 1500 | +$ git merge kn/ref-transaction-symref</code></pre> |
| 1501 | +</div></div> |
| 1502 | +<div class="paragraph"><p>The "revert" is needed if the previous iteration of your topic is |
| 1503 | +already in <em>seen</em> (like in this case). You could choose to rebuild |
| 1504 | +master..origin/seen from scratch while excluding your previous |
| 1505 | +iteration, which may emulate what happens on the maintainers end more |
| 1506 | +closely.</p></div> |
| 1507 | +<div class="paragraph"><p>This trial merge may conflict. It is primarily to see what conflicts |
| 1508 | +<em>other</em> topics may have with your topic. In other words, you do not |
| 1509 | +have to depend on it to make your topic work on <em>master</em>. It may |
| 1510 | +become the job of the other topic owners to resolve conflicts if your |
| 1511 | +topic goes to <em>next</em> before theirs.</p></div> |
| 1512 | +<div class="paragraph"><p>Make a note on what conflict you saw in the cover letter. You do not |
| 1513 | +necessarily have to resolve them, but it would be a good opportunity to |
| 1514 | +learn what others are doing in related areas.</p></div> |
| 1515 | +<div class="literalblock"> |
| 1516 | +<div class="content"> |
| 1517 | +<pre><code>$ git checkout --detach 'origin/next' |
| 1518 | +$ git merge kn/ref-transaction-symref</code></pre> |
| 1519 | +</div></div> |
| 1520 | +<div class="paragraph"><p>This is to see what conflicts your topic has with other topics that are |
| 1521 | +already cooking. This should not conflict if (3)-2 prepared a base on |
| 1522 | +top of updated master plus dependent topics taken from <em>next</em>. Unless |
| 1523 | +the context is severe (one way to tell is try the same trial merge with |
| 1524 | +your old iteration, which may conflict in a similar way), expect that it |
| 1525 | +will be handled on maintainers end (if it gets unmanageable, I’ll ask to |
| 1526 | +rebase when I receive your patches).</p></div> |
| 1527 | +</li> |
| 1528 | +</ol></div> |
| 1529 | +</div> |
1425 | 1530 | </div>
|
1426 | 1531 | </div>
|
1427 | 1532 | <div class="sect1">
|
@@ -1464,6 +1569,19 @@ <h2 id="_subsystems_with_dedicated_maintainers">Subsystems with dedicated mainta
|
1464 | 1569 | </li>
|
1465 | 1570 | </ul></div>
|
1466 | 1571 | <div class="paragraph"><p>Patches to these parts should be based on their trees.</p></div>
|
| 1572 | +<div class="ulist"><ul> |
| 1573 | +<li> |
| 1574 | +<p> |
| 1575 | +The "Git documentation translations" project, led by Jean-Noël |
| 1576 | + Avila, translates our documentation pages. Their work products are |
| 1577 | + maintained separately from this project, not as part of our tree: |
| 1578 | +</p> |
| 1579 | +<div class="literalblock"> |
| 1580 | +<div class="content"> |
| 1581 | +<pre><code>https://github.com/jnavila/git-manpages-l10n/</code></pre> |
| 1582 | +</div></div> |
| 1583 | +</li> |
| 1584 | +</ul></div> |
1467 | 1585 | </div>
|
1468 | 1586 | </div>
|
1469 | 1587 | <div class="sect1">
|
@@ -1590,7 +1708,7 @@ <h3 id="_gnus">Gnus</h3>
|
1590 | 1708 | <div id="footer">
|
1591 | 1709 | <div id="footer-text">
|
1592 | 1710 | Last updated
|
1593 |
| - 2024-05-23 12:14:59 PDT |
| 1711 | + 2024-05-28 13:39:08 PDT |
1594 | 1712 | </div>
|
1595 | 1713 | </div>
|
1596 | 1714 | </body>
|
|
0 commit comments