git/Documentation/SubmittingPatches, branch v2.46.2

Merge branch 'kn/patch-iteration-doc'

2024-05-28T18:17:06Z

Doc updates. * kn/patch-iteration-doc: SubmittingPatches: add section for iterating patches

Merge branch 'jc/doc-manpages-l10n'

2024-05-28T18:17:05Z

The SubmittingPatches document now refers folks to manpages translation project. * jc/doc-manpages-l10n: SubmittingPatches: advertise git-manpages-l10n project a bit

Merge branch 'jc/patch-flow-updates'

2024-05-23T18:04:27Z

Doc updates. * jc/patch-flow-updates: SubmittingPatches: extend the "flow" section SubmittingPatches: move the patch-flow section earlier

SubmittingPatches: advertise git-manpages-l10n project a bit

2024-05-17T17:35:58Z

The project takes our AsciiDoc sources of documentation and actively maintains the translations to various languages. Let's give them enhanced visibility to help those who want to volunteer find them. Acked-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

SubmittingPatches: add section for iterating patches

2024-05-17T17:31:45Z

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 provides the necessary steps that users can follow to reduce 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 Suggested-by: Junio C Hamano Signed-off-by: Karthik Nayak Signed-off-by: Junio C Hamano

Merge branch 'jc/patch-flow-updates' into kn/patch-iteration-doc

2024-05-17T17:31:38Z

* jc/patch-flow-updates: SubmittingPatches: extend the "flow" section SubmittingPatches: move the patch-flow section earlier

Merge branch 'jc/git-gui-maintainer-update'

2024-05-13T17:19:48Z

* jc/git-gui-maintainer-update: SubmittingPatches: welcome the new maintainer of git-gui part

SubmittingPatches: welcome the new maintainer of git-gui part

2024-05-11T21:31:30Z

Signed-off-by: Junio C Hamano

SubmittingPatches: extend the "flow" section

2024-05-10T17:26:14Z

Explain a full lifecycle of a patch series upfront, so that it is clear when key decisions to "accept" a series is made and how a new patch series becomes a part of a new release. Fold the "you need to monitor the progress of your topic" section into the primary "patch lifecycle" section, as that is one of the things the patch submitter is responsible for. It is not like "I sent a patch and responded to review messages, and now it is their problem". They need to see their patch through the patch life cycle. Earlier versions of this document outlined a slightly different patch flow in an idealized world, where the original submitter gathered agreements from the participants of the discussion and sent the final "we all agreed that this is the good version--please apply" patches to the maintainer. In practice, this almost never happened. Instead, describe what flow was used in practice for the past decade that worked well for us. Signed-off-by: Junio C Hamano

SubmittingPatches: move the patch-flow section earlier

2024-05-10T17:26:12Z

Before discussing the small details of how the patch gets sent, we'd want to give people a larger picture first to set the expectation straight. The existing patch-flow section covers materials that are suitable for that purpose, so move it to the beginning of the document. We'll update the contents of the section to clarify what goal the patch submitter is working towards in the next step, which will make it easier to understand the reason behind the individual rules presented in latter parts of the document. This step only moves two sections (patch-flow and patch-status) without changing their contents, except that their section levels are demoted from Level 1 to Level 2 to fit better in the document structure at their new place. Signed-off-by: Junio C Hamano