patchSubmittingPatches: abandoning a series
3 messages between Jul 8, 2026 and Jul 8, 2026, from Junio C Hamano, Michael Montalbo.
Plain Markdown or JSON for tools and agents. Diffs are folded; open one to read it.
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(+)
Show changes to diff +15 −0
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
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(+)
Show changes to Documentation/SubmittingPatches +14 −0
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
On Wed, Jul 08, 2026 at 10:09:49AM -0700, Junio C Hamano wrote:
Show 42 quoted lines
> 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.