1

docs: process: fix typos in Documentation/process/backporting.rst

Change 'submiting' to 'submitting', 'famliar' to 'familiar' and
'appared' to 'appeared'.

Signed-off-by: Aryabhatta Dey <aryabhattadey35@gmail.com>
Reviewed-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/rd2vu7z2t23ppafto4zxc6jge5mj7w7xnpmwywaa2e3eiojgf2@poicxprsdoks
This commit is contained in:
Aryabhatta Dey 2024-08-25 17:03:40 +05:30 committed by Jonathan Corbet
parent 0769a1b7cf
commit 6e56774c17

View File

@ -73,7 +73,7 @@ Once you have the patch in git, you can go ahead and cherry-pick it into
your source tree. Don't forget to cherry-pick with ``-x`` if you want a
written record of where the patch came from!
Note that if you are submiting a patch for stable, the format is
Note that if you are submitting a patch for stable, the format is
slightly different; the first line after the subject line needs tobe
either::
@ -147,7 +147,7 @@ divergence.
It's important to always identify the commit or commits that caused the
conflict, as otherwise you cannot be confident in the correctness of
your resolution. As an added bonus, especially if the patch is in an
area you're not that famliar with, the changelogs of these commits will
area you're not that familiar with, the changelogs of these commits will
often give you the context to understand the code and potential problems
or pitfalls with your conflict resolution.
@ -197,7 +197,7 @@ git blame
Another way to find prerequisite commits (albeit only the most recent
one for a given conflict) is to run ``git blame``. In this case, you
need to run it against the parent commit of the patch you are
cherry-picking and the file where the conflict appared, i.e.::
cherry-picking and the file where the conflict appeared, i.e.::
git blame <commit>^ -- <path>