[PATCH] doc: process: clarify legacy status of applying-patches and point to Git

[PATCH] doc: process: clarify legacy status of applying-patches and point to Git

[Oscar Alejandro Sánchez Lucero via B4 Relay]

From: Oscar Alejandro Sánchez Lucero <aleszlucero@gmail.com>

The applying-patches.rst document heavily details the legacy 'patch'
utility, which creates confusion for new contributors since current
development relies almost entirely on Git infrastructure.

This patch updates the opening notes to explicitly mark the manual
patching process as a legacy reference and redirects readers to
contemporary Git-based guides.

Signed-off-by: Oscar Alejandro Sánchez Lucero <aleszlucero@gmail.com>
---
The applying-patches.rst document heavily details the legacy 'patch'
utility, which creates confusion for new contributors since current
development relies almost entirely on Git infrastructure.

This series updates the introduction to explicitly mark the manual 
patching process as a legacy reference and redirects readers to 
contemporary Git-based guides.

Thanks to Randy Dunlap, Krzysztof Kozlowski, and Weijie Yuan for 
their initial conceptual review and support.
---
 Documentation/process/applying-patches.rst | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/process/applying-patches.rst b/Documentation/process/applying-patches.rst
index c269f5e1a0a3..2ccd74d6dd05 100644
--- a/Documentation/process/applying-patches.rst
+++ b/Documentation/process/applying-patches.rst
@@ -8,8 +8,14 @@ Original by:
 
 .. note::
 
-   This document is obsolete.  In most cases, rather than using ``patch``
-   manually, you'll almost certainly want to look at using Git instead.
+   This document focuses on the legacy method of manually manipulating source
+   trees using the traditional ``patch`` and ``diff`` utilities.
+
+   For the standard Git-based workflow used to clone the repository and work
+   with kernel patches, please refer to Documentation/process/howto.rst.
+
+   The information below is maintained as a reference for constrained
+   environments or legacy workflows where Git infrastructure is unavailable.
 
 A frequently asked question on the Linux Kernel Mailing List is how to apply
 a patch to the kernel or, more specifically, what base kernel a patch for

---
base-commit: ddfe51b0a0f5dc9e415cc2c8ad8db17532dd426b
change-id: 20261106-doc-modernize-git-1eae13a1e623

Best regards,
-- 
Oscar Alejandro Sánchez Lucero <aleszlucero@gmail.com>

Re: [PATCH] doc: process: clarify legacy status of applying-patches and point to Git

[Jonathan Corbet]

Oscar Alejandro Sánchez Lucero via B4 Relay
<devnull+aleszlucero.gmail.com@kernel.org> writes:

> From: Oscar Alejandro Sánchez Lucero <aleszlucero@gmail.com>
>
> The applying-patches.rst document heavily details the legacy 'patch'
> utility, which creates confusion for new contributors since current
> development relies almost entirely on Git infrastructure.
>
> This patch updates the opening notes to explicitly mark the manual
> patching process as a legacy reference and redirects readers to
> contemporary Git-based guides.
>
> Signed-off-by: Oscar Alejandro Sánchez Lucero <aleszlucero@gmail.com>

So how does this relate to the other patch that you sent six times in
quick succession?

> The applying-patches.rst document heavily details the legacy 'patch'
> utility, which creates confusion for new contributors since current
> development relies almost entirely on Git infrastructure.
>
> This series updates the introduction to explicitly mark the manual 
> patching process as a legacy reference and redirects readers to 
> contemporary Git-based guides.

...and why are you repeating this text here?

Thanks,

jon

Re: [PATCH] doc: process: clarify legacy status of applying-patches and point to Git

[Alejandro Lucero]

Hi Jon,

Sorry for the confusion and the noise. The six earlier messages were
accidental resends while I was learning how to manage revisions in b4-
please disregard them.

This single patch is meant to replace those earlier attempts (I also
accidentally duplicated the commit message into the cover letter).
Would you like me to resend it as a clean single-patch v2 without a
cover letter, or is this version fine as-is?

Thanks,
Oscar