Thread (4 messages) 4 messages, 2 authors, 2024-05-17

Re: [PATCH] SubmittingPatches: add section for iterating patches

From: Patrick Steinhardt <hidden>
Date: 2024-05-17 05:15:40

On Tue, May 14, 2024 at 02:30:39PM +0200, Karthik Nayak wrote:
From: Karthik Nayak <redacted>

Add a section to explain how to work around other in-flight patches and
how to navigate conflicts which arise as a series is being iterated.
This will provide the necessary steps that users can follow to reduce
s/This will/This provides/
friction with other ongoing topics and also provides guidelines on how
the users can also communicate this to the list efficiently.

Co-authored-by: Junio C Hamano [off-list ref]
Suggested-by: Junio C Hamano <redacted>
Signed-off-by: Karthik Nayak <redacted>
---

This came off a discussion wherein I sent a series based on `next`
instead of merging in conflicts [1]. This is mostly worded by Junio and
I've just put it together into a patch.

This is based off master, with 'jc/patch-flow-updates' merged in.
:)
quoted hunk ↗ jump to hunk
[1]: https://lore.kernel.org/git/xmqqy18lpoqg.fsf@gitster.g/ (local)

 Documentation/SubmittingPatches | 79 +++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 8332073e27..2fd94dc8de 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -608,6 +608,85 @@ patch, format it as "multipart/signed", not a text/plain message
 that starts with `-----BEGIN PGP SIGNED MESSAGE-----`.  That is
 not a text/plain, it's something else.
 
+=== Handling Conflicts and Iterating Patches
+
+When revising changes made to your patches, it's important to
+acknowledge the possibility of conflicts with other ongoing topics. To
+navigate these potential conflicts effectively, follow the recommended
+steps outlined below:
Okay. I was first wondering why we only mention conflicts when revising
changes. But I see there are other parts in the document where we
already mention the potential for conflicts, so this is fine.
+. Build on a suitable base branch, see the <<choose-starting-point, section above>>,
+and format-patch the series. If you are doing "rebase -i" in-place to
+update from the previous round, this will reuse the previous base so
+(2) and (3) may become trivial.
+
+. Find the base of where the last round was queued
It's somewhat unusual for bulleted lists to start with a dot, but this
is consistent with the remainder of this document.

[snip]
+Do not forget to write in the cover letter you did this, including the
+topics you have in your base on top of 'master'.  Then go to (4).
+
+. Make a trial merge of your topic into 'next' and 'seen', e.g.
++
+    $ git checkout --detach 'origin/seen' &&
+    $ git revert -m 1 <the merge of the previous iteration into seen> &&
+    $ git merge kn/ref-transaction-symref
Let's remove the trailing '&&' lines. The leading dollar indicates that
this is interactive, so you wouldn't concatenate the commands like this.
Also, preceding code didn't have it.
+The "revert" is needed if the previous iteration of your topic is
+already in 'seen' (like in this case).  You could choose to rebuild
+master..origin/seen from scratch while excluding your previous
+iteration, which may emulate what happens on the maintainers end more
+closely.
++
+This trial merge may conflict.  It is primarily to see what conflicts
+_other_ topics may have with your topic.  In other words, you do not
+have to depend on to make your topic work on 'master'.  It may become
I think there's either a word too many or missing  -- depend on what?
+the job of the other topic owners to resolve conflicts if your topic
+goes to 'next' before theirs.
++
+Make a note on what conflict you saw in the cover letter.  You do not
+necessarily have to resolve them, but it would be a good opportunity to
+learn what others are doing in an related area.
s/an/a
++
+    $ git checkout --detach 'origin/next' &&
+    $ git merge kn/ref-transaction-symref
Same comment here regarding the ampersands.

Other than that the additions look good to me, thanks!

Patrick

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help