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 " 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 ` - -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 `. 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 ` - -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 ` - -For example, if you rebased against `gdb-8.1-release`: - -`$ sh generate-patches-from-git-repo.sh 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 " 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 ` + +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 `. 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 ` + +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 ` + +For example, if you rebased against `gdb-8.1-release`: + +`$ sh generate-patches-from-git-repo.sh gdb-8.1-release`