public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
From: Sergio Durigan Junior <sergiodj@redhat.com>
To: git-commits@fedoraproject.org
Subject: [rpms/gdb] gdb-17.2-rebase-f44: Reformat README.local-patches to Markdown.
Date: Sat, 27 Jun 2026 23:59:55 GMT	[thread overview]
Message-ID: <178260479549.1.3933844535153098606.rpms-gdb-2a1cf3d88136@fedoraproject.org> (raw)

A new commit has been pushed.

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

Log:
Reformat README.local-patches to Markdown.

---
diff --git a/README.local-patches b/README.local-patches
index 725846e..fc2eb90 100644
--- a/README.local-patches
+++ b/README.local-patches
@@ -1,5 +1,4 @@
-Fedora GDB local patches policy
-===============================
+# 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
@@ -9,42 +8,42 @@ 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
+## Importing the GDB patches into a git repository
 
-1) The local patches (*.patch) need to be imported into an upstream
+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
+`$ 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.
+> 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>
+`$ 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*.
+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.
+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
+## 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
+`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
+## 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
+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
@@ -54,48 +53,52 @@ used when exporting the patches from the git repository, and
 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
+`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:
+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
+## 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:
+that contains the `gdb.spec` file, and from there you run:
 
-  $ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR>
+`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR>`
 
-This will regenerate all of the *.patch files (excluding the ones that
+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.
 
-  - _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
+  - `_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
+  - `_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>
+`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR> <COMMIT_OR_TAG_OR_BRANCH>`
 
-For example, if you rebased against "gdb-8.1-release":
+For example, if you rebased against `gdb-8.1-release`:
 
-  $ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR> gdb-8.1-release
+`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR> gdb-8.1-release`

                 reply	other threads:[~2026-06-27 23:59 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=178260479549.1.3933844535153098606.rpms-gdb-2a1cf3d88136@fedoraproject.org \
    --to=sergiodj@redhat.com \
    --cc=git-commits@fedoraproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox