Use new gbp <command> syntax

1 files changed, 16 insertions, 16 deletions

diff --git a/development/debian_packages_in_git.mdwn b/development/debian_packages_in_git.mdwn
index 57f6d1c..b68ae5c 100644
--- a/development/debian_packages_in_git.mdwn
+++ b/development/debian_packages_in_git.mdwn
@@ -20,14 +20,14 @@ Assuming the Debian source package has it's patches in *debian/patches* and thes
 * Create *patch-queue* branch and import *debian/patches* onto it using gbp-pq:
 
         cd $REPO
-        gbp-pq import
+        gbp pq import
 * This will switch you to the patch-queue branch automatically. If you started from *master* the patch-queue branch will be called *patch-queue/master*.
 * Now you can work on the patch-queue branch (add, remove, rebase, test) to get your patches into shape:
     * To add what will later become a patch in *debian/patches/* simply make a commit. The first line of the commit message will become the patch name later. The following lines include the details of what the patch does.
     * To remove or edit commits use *git rebase -i master*. The [git documentation][] explains how to work with git-rebase.
 * Regenerate the patches in *debian/patches/* using gbp-pq. This will switch you back to *master* and regenerate the patches using *git-format-patch(1)*:
 
-        gbp-pq export
+        gbp pq export
 * Commit the result either by using *gbp-add-patch* or simply
 
         git add debian/patches
@@ -36,14 +36,14 @@ Assuming the Debian source package has it's patches in *debian/patches* and thes
 * Build the package
 * After importing a new upstream version you can use the following commands to refresh *debian/patches*:
 
-        gbp-pq rebase
+        gbp pq rebase
         git checkout master
-        gbp-pq export
+        gbp pq export
 * If a package doesn't have any patches yet, these are the steps to add your first patch:
 
     1. Launch an import, this will switch to the proper branch
 
-            gbp-pq import
+            gbp pq import
     2. Create your first patch:
 
           * Edit files / Test
@@ -51,7 +51,7 @@ Assuming the Debian source package has it's patches in *debian/patches* and thes
     3. Back to the master branch, generate the Quilt patch set
 
             git checkout master
-            gbp-pq export
+            gbp pq export
     4. Commit you first patch
         
             git add -a debian/patches/
@@ -64,7 +64,7 @@ If you want to pick the changelog message from the patch see
 The easiest way is to not push out any patch-queue/* branches at all. They can be recreated by any team member easily by using
 
     git branch -d patch-queue/master
-    gbp-pq import
+    gbp pq import
 
 However you *can* push out patch-queue branches. Other team members must just be aware that that branches in the *patch-queue/* namespace are being rebased frequently.
 
@@ -84,23 +84,23 @@ If you're using option *--git-export-dir* option already there's no problem sinc
 ## Working from a patch-queue branch
 Instead of building from *master* build from *patch-queue/master* prepared by *gbp-pq* as describe above. This branch has the patches already applied as dpkg-source expects it:
     
-    gbp-pq import
-    git-buildpackage --git-debian-branch=patch-queue/master
+    gbp pq import
+    gbp buildpackage --git-debian-branch=patch-queue/master
 Build and test...
 
     git checkout master
-    gbp-pq export
+    gbp pq export
 
 # Cloning a repository
-If you use *gbp-clone* instead of *git clone* to clone a remote repository it will automatically set up the *debian*, *upstream* and *pristine-tar* branches for you. The [manual][] explains the terminology.
+If you use *gbp clone* instead of *git clone* to clone a remote repository it will automatically set up the *debian*, *upstream* and *pristine-tar* branches for you. The [manual][] explains the terminology.
 
 # Keeping a repository up to date
-After initially cloning with *gbp-clone* you can run *gbp-pull* to update your
+After initially cloning with *gbp clone* you can run *gbp pull* to update your
 *debian*, *upstream* and *pristine-tar* branches from the remote site. So the
 complete workflow for simple team maintenance looks like this:
 
     # Initially clone the repo once
-    gbp-clone git://git.debian.org/pkg-libvirt/gtk-vnc.git
+    gbp clone git://git.debian.org/pkg-libvirt/gtk-vnc.git
     cd gtk-vnc
 
 Work on that clone, commit, release, push, etc. Now after a couple of days you
@@ -108,14 +108,14 @@ want to make more changes but don't know if another developer worked on it. So
 you do:
 
     # Update to what others might have pushed
-    gbp-pull
+    gbp pull
 
 This will update all necessary branches to what other developers might have
 pushed in the meantime. If you're also using a patch-queue as described above
 you can refresh that too in one step:
 
     # Update to what others might have pushed and rebuild patch-queue
-    gbp-pull --redo-pq    
+    gbp pull --redo-pq
 
 This will additionally drop your current patch-queue branch and recreate it from debian/patches.
 
@@ -126,7 +126,7 @@ I keep backports on a separate *bpo-<release>* branch like *bpo-lenny*:
     git merge debian/<version-currently-in-testing>
     <resolve conflict in debian/changelog>
     <fix up stuff needed for backport>
-    git-buildpackage --git-pbuilder --git-dist=lenny -sa -v <last-backported-version> --git-debian-branch=bpo-lenny
+    gbp buildpackage --git-pbuilder --git-dist=lenny -sa -v <last-backported-version> --git-debian-branch=bpo-lenny
 
 In order to avoid the merge conflict in the changelog have a look at *dpkg-mergechangelogs(1)*. To create the necessary cowbuilder chroot for Lenny use: