[PATCH] SubmittingPatches: abandoning a series

[PATCH] SubmittingPatches: abandoning a series

[Junio C Hamano]

The document describes an idealized life cycle for a patch series,
where an author scratches their itch, improves the patch(es) with
help from fellow reviewers, and iterate until their work becomes a
part of Git.

But sometimes a topic may have to be abandoned or retracted, with an
option to later resurrect it when they can, and it is much better
than leaving a topic in limbo.  Clearly state that we encourage
contributors to explicitly retract their topic that did not succeed.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/SubmittingPatches | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git c/Documentation/SubmittingPatches w/Documentation/SubmittingPatches
index f042bb5aaf..f14ae20aaa 100644
--- c/Documentation/SubmittingPatches
+++ w/Documentation/SubmittingPatches
@@ -95,6 +95,21 @@ input and avoids unnecessary churn from many rapid iterations.
   top, it gets merged to the 'master' branch and waits to become part
   of the next major release.
 
+But sometimes things do not work as planned.
+
+. A discussion on the list might convince you that your changes are
+  not such a good idea, in which case you are expected to explicitly
+  retract the topic, to releave the maintainer from having to worry
+  about it.
+
+. You may have to stop pursuing the topic due to various reasons like
+  lack of time, other commitments, shifting priorities, etc.  It is a
+  friendly thing to do to tell the list in such a case, so that others
+  interested in the topic can take over the topic and continue.  When
+  there is no taker, the maintainer may have to discard the topic, but
+  anybody can resurrect the topic later when they (including you) can
+  spend more time on it.
+
 In the following sections, many techniques and conventions are listed
 to help your patches get reviewed effectively in such a life cycle.
 

[PATCH v2] SubmittingPatches: document how to retract a topic

[Junio C Hamano]

While this document outlines an idealized lifecycle where an author
develops a patch, refines it with reviewer feedback, and
successfully merges it into Git, reality is rarely so seamless.

Sometimes, a topic must be abandoned. Doing so explicitly is far
better than leaving it in limbo, especially since topics can always
be resurrected later.

Clearly state that we encourage contributors to retract any topic
that does not pan out.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * Added the third bullet that talks about when and how a topic
   becomes stalled and discarded.

 Documentation/SubmittingPatches | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index d2d82eb543..c269e474e3 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -123,6 +123,20 @@ of review.
   top, it gets merged to the 'master' branch and waits to become part
   of the next major release.
 
+But sometimes things do not work as planned:
+
+. If a mailing list discussion convinces you that your changes aren't
+  ideal, please explicitly retract the topic to save the maintainer
+  time and effort.
+
+. If you must drop a topic due to shifting priorities, lack of time,
+  or other commitments, notify the list as a courtesy so others can
+  take over. Anyone can resurrect the topic later when they have the
+  capacity to do so.
+
+. Topics with unaddressed review comments that remain inactive for
+  four weeks may be discarded by the maintainer.
+
 In the following sections, many techniques and conventions are listed
 to help your patches get reviewed effectively in such a life cycle.
 
-- 
2.55.0-302-gdbd766b094

Re: [PATCH v2] SubmittingPatches: document how to retract a topic

[Michael Montalbo]

On Wed, Jul 08, 2026 at 10:09:49AM -0700, Junio C Hamano wrote:
> While this document outlines an idealized lifecycle where an author
> develops a patch, refines it with reviewer feedback, and
> successfully merges it into Git, reality is rarely so seamless.
> 
> Sometimes, a topic must be abandoned. Doing so explicitly is far
> better than leaving it in limbo, especially since topics can always
> be resurrected later.
> 
> Clearly state that we encourage contributors to retract any topic
> that does not pan out.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> 
>  * Added the third bullet that talks about when and how a topic
>    becomes stalled and discarded.
> 
>  Documentation/SubmittingPatches | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index d2d82eb543..c269e474e3 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -123,6 +123,20 @@ of review.
>    top, it gets merged to the 'master' branch and waits to become part
>    of the next major release.
>  
> +But sometimes things do not work as planned:
> +
> +. If a mailing list discussion convinces you that your changes aren't
> +  ideal, please explicitly retract the topic to save the maintainer
> +  time and effort.
> +
> +. If you must drop a topic due to shifting priorities, lack of time,
> +  or other commitments, notify the list as a courtesy so others can
> +  take over. Anyone can resurrect the topic later when they have the
> +  capacity to do so.
> +
> +. Topics with unaddressed review comments that remain inactive for
> +  four weeks may be discarded by the maintainer.
> +

Nice, I think these points read smoothly and the additional "four weeks
until may be discarded" guidance is helpful.

LGTM.