gbp-pq(1) [debian man page]
GBP-PQ(1) git-buildpackage Manual GBP-PQ(1) NAME
gbp-pq - Manage quilt patches on patch queue branches in git SYNOPSIS
gbp-pq [ --verbose ] [ --color=[auto|on|off] ] [ --[no-]patch-numbers ] [ --topic=topic ] [ --time-machine=num ] drop | export | import | rebase | switch DESCRIPTION
gbp-pq helps one to manage quilt patches in Debian packages that are maintained with git-buildpackage. This is especially useful with pack- ages using the 3.0 (quilt) source format. With gbp-pq you can maintain the quilt patches that should be applied to a package on a separate branch called patch-queue branch. So if your Debian package lives on master the associated patch-queue branch will be called patch- queue/master. See <URL:https://honk.sigxcpu.org/piki/development/debian_packages_in_git/> for example workflows. ACTIONS
import Create a patch queue branch from quilt patches in debian/patches/ that are listed in debian/patches/series. export Export the patches on the patch-queue branch associated to the current branch into a quilt patch series in debian/patches/ and update the series file. rebase Switch to the patch-queue branch associated to the current branch and rebase it against the current branch. drop Drop (delete) the patch queue associated to the current branch. So if you're on branch foo this would drop branch patch-queue/foo. apply Add a single patch to the patch-queue similar to using git-am. Use --topic if you want the patch to appear in a separate subdir when exporting the patch queue using export. This can be used to separate upstream pathes from debian specific patches. switch Switch to the patch-queue branch if on the base branch and switch to base branch if on patch-queue branch. OPTIONS
--verbose -v verbose execution --color=[auto|on|off] Whether to use colored output. --[no-]patch-numbers Whether the patch files should start with a number or not. --topic=topic Topic to use when importing a single patch --time-machine=NUM When importing a patch queue fails, go back commit by commit on the current branch to check if the patch-queue applies there. Do this at most NUM times. This can be useful if the patch-queue doesn't apply to the current branch HEAD anymore, e.g. after import- ing a new upstream version. TAGS
When exporting patches from a patch-queue branch gbp-pq will look at the patch header for special tags it recognizes. All tags need to start at the first column and require at least one whitespace after the colon. Gbp-Pq-Topic: topic Moves the patch into a subdir called topic when running gbp-pq export . This allows for some structure below debian/patches. SEE ALSO
git-buildpackage(1), dpkg-source(1), quilt(1), gbp.conf(5) AUTHOR
Guido Guenther <agx@sigxcpu.org> 01 June 2012 GBP-PQ(1)
Check Out this Related Man Page
GIT-CHERRY(1) Git Manual GIT-CHERRY(1) NAME
git-cherry - Find commits yet to be applied to upstream SYNOPSIS
git cherry [-v] [<upstream> [<head> [<limit>]]] DESCRIPTION
Determine whether there are commits in <head>..<upstream> that are equivalent to those in the range <limit>..<head>. The equivalence test is based on the diff, after removing whitespace and line numbers. git-cherry therefore detects when commits have been "copied" by means of git-cherry-pick(1), git-am(1) or git-rebase(1). Outputs the SHA1 of every commit in <limit>..<head>, prefixed with - for commits that have an equivalent in <upstream>, and + for commits that do not. OPTIONS
-v Show the commit subjects next to the SHA1s. <upstream> Upstream branch to search for equivalent commits. Defaults to the upstream branch of HEAD. <head> Working branch; defaults to HEAD. <limit> Do not report commits up to (and including) limit. EXAMPLES
Patch workflows git-cherry is frequently used in patch-based workflows (see gitworkflows(7)) to determine if a series of patches has been applied by the upstream maintainer. In such a workflow you might create and send a topic branch like this: $ git checkout -b topic origin/master # work and create some commits $ git format-patch origin/master $ git send-email ... 00* Later, you can see whether your changes have been applied by saying (still on topic): $ git fetch # update your notion of origin/master $ git cherry -v Concrete example In a situation where topic consisted of three commits, and the maintainer applied two of them, the situation might look like: $ git log --graph --oneline --decorate --boundary origin/master...topic * 7654321 (origin/master) upstream tip commit [... snip some other commits ...] * cccc111 cherry-pick of C * aaaa111 cherry-pick of A [... snip a lot more that has happened ...] | * cccc000 (topic) commit C | * bbbb000 commit B | * aaaa000 commit A |/ o 1234567 branch point In such cases, git-cherry shows a concise summary of what has yet to be applied: $ git cherry origin/master topic - cccc000... commit C + bbbb000... commit B - aaaa000... commit A Here, we see that the commits A and C (marked with -) can be dropped from your topic branch when you rebase it on top of origin/master, while the commit B (marked with +) still needs to be kept so that it will be sent to be applied to origin/master. Using a limit The optional <limit> is useful in cases where your topic is based on other work that is not in upstream. Expanding on the previous example, this might look like: $ git log --graph --oneline --decorate --boundary origin/master...topic * 7654321 (origin/master) upstream tip commit [... snip some other commits ...] * cccc111 cherry-pick of C * aaaa111 cherry-pick of A [... snip a lot more that has happened ...] | * cccc000 (topic) commit C | * bbbb000 commit B | * aaaa000 commit A | * 0000fff (base) unpublished stuff F [... snip ...] | * 0000aaa unpublished stuff A |/ o 1234567 merge-base between upstream and topic By specifying base as the limit, you can avoid listing commits between base and topic: $ git cherry origin/master topic base - cccc000... commit C + bbbb000... commit B - aaaa000... commit A SEE ALSO
git-patch-id(1) GIT
Part of the git(1) suite Git 2.17.1 10/05/2018 GIT-CHERRY(1)