[policy] 01/01: git-import-orig is now gbp import-orig

[Andreas Tille]

This is an automated email from the git hooks/post-receive script.

tille pushed a commit to branch master
in repository policy.

commit 718bf28f7628e8c3742e36ffa5fe0f55de83fb7d
Author: Andreas Tille <tille at debian.org>
Date:   Mon Apr 4 16:48:44 2016 +0200

    git-import-orig is now gbp import-orig
---
 debian-science-policy.xml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian-science-policy.xml b/debian-science-policy.xml
index 7a1bdd6..812d159 100644
--- a/debian-science-policy.xml
+++ b/debian-science-policy.xml
@@ -375,7 +375,7 @@ $ git config user.email "$DEBEMAIL"
 	<para>pristine-tar is able to recreate bit-identical upstream tar-balls from the files stored under version control. It does so by creating small delta files, so that it is not necessary to store the whole tar-ball.</para>
 	<para>To import an upstream tar-ball into your repository, simply run:</para>
 	<screen><![CDATA[
-$ git import-orig --pristine-tar ~/foo_1.0.orig.tar.gz
+$ gbp import-orig --pristine-tar ~/foo_1.0.orig.tar.gz
 Upstream version is 1.0
 Initial import of '/home/jdoe/foo_1.0.orig.tar.gz' ...
 pristine-tar: committed foo_1.0.orig.tar.gz.delta to branch pristine-tar
@@ -393,7 +393,7 @@ $ git branch
 $ git tag -l
 upstream/1.0
 ]]></screen>
-	<para>You can use git-import-orig for every new upstream tar-ball. It will extract the sources to the upstream branch and merge them back to the master branch.</para>
+	<para>You can use <command>gbp import-orig</command> for every new upstream tar-ball. It will extract the sources to the upstream branch and merge them back to the master branch.</para>
       </sect3>
     </sect2>
     <sect2>
@@ -404,7 +404,7 @@ upstream/1.0
 	<para>By using this model, all changes to the upstream sources are made in independent branches and merged back into a special branch, the "integration" branch. This section tries to explain how this works.</para>
 	<para>When doing changes to the upstream sources, all logical changes should be stored in their own branch, a so-called "feature branch". The hardest part is giving it a reasonable name. If you want to fix a bug submitted to the BTS, you might want to call your branch "bug-nnn", where "nnn" is the bug number. You can also prefix Debian-specific changes with "deb/" to separate them from branches that contain patches which might be included upstream.</para>
 	<note><para>You can also store each patch as one commit in a single feature branch, such as "upstream-patches". It is all up to you. Figure out what work-flow you like best.</para></note>
-	<para>After you thought of a name, you should branch from the latest upstream version. If you used git-import-orig, you can use the tags created by it:</para>
+	<para>After you thought of a name, you should branch from the latest upstream version. If you used <command>gbp import-orig</command>, you can use the tags created by it:</para>
 	<screen><![CDATA[
 $ git checkout -b bug-123456 upstream/1.0
 ]]></screen>

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/debian-science/policy.git