[rpms/gdb] gdb-17.2-rebase-f44: Rename README.local-patches to README.local-patches.md

[Sergio Durigan Junior <sergiodj@redhat.com>]

A new commit has been pushed.

Repo   : rpms/gdb
Branch : gdb-17.2-rebase-f44
Commit : cd3e3d1a800c883070e5ee7847f3e2813558cd62
Author : Sergio Durigan Junior <sergiodj@redhat.com>
Date   : 2020-02-11T15:34:42-05:00
Stats  : +104/-104 in 2 file(s)
URL    : https://src.fedoraproject.org/rpms/gdb/c/cd3e3d1a800c883070e5ee7847f3e2813558cd62?branch=gdb-17.2-rebase-f44

Log:
Rename README.local-patches to README.local-patches.md

---
diff --git a/README.local-patches b/README.local-patches
deleted file mode 100644
index fc2eb90..0000000
--- a/README.local-patches
+++ /dev/null
@@ -1,104 +0,0 @@
-# Fedora GDB local patches policy
-
-In order to make things easier for the Fedora GDB maintainer, we
-choose to auto-generate the local patches by making use of an upstream
-git repository.  Below you can find a few instructions on how to work
-using this method.
-
-You need to run the following commands from the directory that
-contains the "gdb.spec" file.
-
-## Importing the GDB patches into a git repository
-
-1) The local patches (`*.patch`) need to be imported into an upstream
-git repository.  For example, let's assume you cloned the repository
-by doing:
-
-`$ git clone git://sourceware.org/git/binutils-gdb.git`
-
-> TIP: if you already have the repository cloned somewhere in your
-> system, you can pass a "--reference <dir>" to the "git clone"
-> command and it will use your local repository as much as possible
-> to make the clone, speeding up things.
-
-2) After cloning the upstream repository, you can import your patches
-by using the script "generate-git-repo-from-patches.sh":
-
-`$ sh generate-git-repo-from-patches.sh <REPOSITORY_DIR>`
-
-The script will basically cd into the repository, checkout the
-revision specified in the file `_git_upstream_commit`, iterate through
-the file `_patch_order` and "git-am" every patch *in that order*.
-This operation should complete without errors; if you find a problem
-with `git-am`, it probably means that the revision specified in the
-file `_git_upstream_commit` is wrong.
-
-## Rebasing the patches against a newer version/release
-
-1) First, cd into the upstream repository.  All you have to do is
-choose the revision against which you plan to rebase the patches, and
-`git rebase <REVISION>`.  git will do the rest, and you will be able
-to perform conflict resolution by git's algorithm, which is smarter.
-
-## Creating new patches
-
-1) Create the new patch on top of the the others, as usual.  Note that
-you can use `git rebase` whenever you want to reorder patch order, or
-even to delete a patch.
-
-2) When writing the commit log, you must obey a few rules.  The
-subject line *must* be the filename of the patch.  This line will be
-used when exporting the patches from the git repository, and
-(obviously) it gives the filename that should be used for this
-specific patch.
-
-3) You can also add comments that will go into the auto-generated
-`Patch:` file (see below).  To do that, use the special marker `;;` at
-the beginning of the line.  This way, a commit log that says:
-
-~~~~~~~~~~~
-  test-patch.patch
-
-  ;; This is a test patch
-  ;; Second line
-~~~~~~~~~~~
-
-Will generate the following entry in the auto-generated `Patch:` file:
-
-~~~~~~~~~~~
-  # This is a test patch
-  # Second line
-  PatchXYZ: test-patch.patch
-~~~~~~~~~~~
-
-## Exporting the GDB patches from the git repository
-
-1) When you're done working with the patches, go back to the directory
-that contains the `gdb.spec` file, and from there you run:
-
-`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR>`
-
-This will regenerate all of the `*.patch` files (excluding the ones that
-were also excluded from the git repository), and also regenerate a few
-control files.  These control files are:
-
-  - `_gdb.spec.Patch.include`: This file contains the `Patch:` directives.
-
-  - `_gdb.spec.patch.include`: This file contains the `%patch` directives.
-
-  - `_patch_order`: This file contains the patches, in the exact order
-    that they must be applied.  It is used when importing the patches
-    into the git repository.
-
-  - `_git_upstream_commit`: This file contains the last upstream commit
-    against which the patches were rebased.  It is used when importing
-    the patches into the git repository.
-
-NOTE: If you did a rebase against a newer upstream version, you need
-to specify the commit/tag/branch against which you rebased:
-
-`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR> <COMMIT_OR_TAG_OR_BRANCH>`
-
-For example, if you rebased against `gdb-8.1-release`:
-
-`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR> gdb-8.1-release`

diff --git a/README.local-patches.md b/README.local-patches.md
new file mode 100644
index 0000000..fc2eb90
--- /dev/null
+++ b/README.local-patches.md
@@ -0,0 +1,104 @@
+# Fedora GDB local patches policy
+
+In order to make things easier for the Fedora GDB maintainer, we
+choose to auto-generate the local patches by making use of an upstream
+git repository.  Below you can find a few instructions on how to work
+using this method.
+
+You need to run the following commands from the directory that
+contains the "gdb.spec" file.
+
+## Importing the GDB patches into a git repository
+
+1) The local patches (`*.patch`) need to be imported into an upstream
+git repository.  For example, let's assume you cloned the repository
+by doing:
+
+`$ git clone git://sourceware.org/git/binutils-gdb.git`
+
+> TIP: if you already have the repository cloned somewhere in your
+> system, you can pass a "--reference <dir>" to the "git clone"
+> command and it will use your local repository as much as possible
+> to make the clone, speeding up things.
+
+2) After cloning the upstream repository, you can import your patches
+by using the script "generate-git-repo-from-patches.sh":
+
+`$ sh generate-git-repo-from-patches.sh <REPOSITORY_DIR>`
+
+The script will basically cd into the repository, checkout the
+revision specified in the file `_git_upstream_commit`, iterate through
+the file `_patch_order` and "git-am" every patch *in that order*.
+This operation should complete without errors; if you find a problem
+with `git-am`, it probably means that the revision specified in the
+file `_git_upstream_commit` is wrong.
+
+## Rebasing the patches against a newer version/release
+
+1) First, cd into the upstream repository.  All you have to do is
+choose the revision against which you plan to rebase the patches, and
+`git rebase <REVISION>`.  git will do the rest, and you will be able
+to perform conflict resolution by git's algorithm, which is smarter.
+
+## Creating new patches
+
+1) Create the new patch on top of the the others, as usual.  Note that
+you can use `git rebase` whenever you want to reorder patch order, or
+even to delete a patch.
+
+2) When writing the commit log, you must obey a few rules.  The
+subject line *must* be the filename of the patch.  This line will be
+used when exporting the patches from the git repository, and
+(obviously) it gives the filename that should be used for this
+specific patch.
+
+3) You can also add comments that will go into the auto-generated
+`Patch:` file (see below).  To do that, use the special marker `;;` at
+the beginning of the line.  This way, a commit log that says:
+
+~~~~~~~~~~~
+  test-patch.patch
+
+  ;; This is a test patch
+  ;; Second line
+~~~~~~~~~~~
+
+Will generate the following entry in the auto-generated `Patch:` file:
+
+~~~~~~~~~~~
+  # This is a test patch
+  # Second line
+  PatchXYZ: test-patch.patch
+~~~~~~~~~~~
+
+## Exporting the GDB patches from the git repository
+
+1) When you're done working with the patches, go back to the directory
+that contains the `gdb.spec` file, and from there you run:
+
+`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR>`
+
+This will regenerate all of the `*.patch` files (excluding the ones that
+were also excluded from the git repository), and also regenerate a few
+control files.  These control files are:
+
+  - `_gdb.spec.Patch.include`: This file contains the `Patch:` directives.
+
+  - `_gdb.spec.patch.include`: This file contains the `%patch` directives.
+
+  - `_patch_order`: This file contains the patches, in the exact order
+    that they must be applied.  It is used when importing the patches
+    into the git repository.
+
+  - `_git_upstream_commit`: This file contains the last upstream commit
+    against which the patches were rebased.  It is used when importing
+    the patches into the git repository.
+
+NOTE: If you did a rebase against a newer upstream version, you need
+to specify the commit/tag/branch against which you rebased:
+
+`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR> <COMMIT_OR_TAG_OR_BRANCH>`
+
+For example, if you rebased against `gdb-8.1-release`:
+
+`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR> gdb-8.1-release`