From 1d90e73e969cebc1aaa6a151dd03da0b271fbb4d Mon Sep 17 00:00:00 2001 From: Guido Günther Date: Wed, 26 Jun 2013 13:09:51 +0200 Subject: docs: Rename the entities from &git-; to &gbp-; --- docs/chapters/building.sgml | 30 +++++++++++++++--------------- docs/chapters/cfgfile.sgml | 14 +++++++------- docs/chapters/import.sgml | 44 ++++++++++++++++++++++---------------------- docs/chapters/intro.sgml | 22 +++++++++++----------- docs/chapters/releases.sgml | 28 ++++++++++++++-------------- docs/chapters/special.sgml | 10 +++++----- 6 files changed, 74 insertions(+), 74 deletions(-) (limited to 'docs/chapters') diff --git a/docs/chapters/building.sgml b/docs/chapters/building.sgml index 159f476..3029672 100644 --- a/docs/chapters/building.sgml +++ b/docs/chapters/building.sgml @@ -2,7 +2,7 @@ Building packages from the &git; repository In order to build a &debian; package from the &git; repository you use: - &git-buildpackage;. This builds the upstream tarball as will be described below and + &gbp-buildpackage;. This builds the upstream tarball as will be described below and invokes &debuild; to build the package. To use another build command you can use the option as described later in the manual but &debuild; is nice since it can invoke lintian. @@ -11,9 +11,9 @@ your repository) you'll usually use: -&git-buildpackage; +&gbp-buildpackage; - If &git-buildpackage; doesn't find a valid upstream tarball it will + If &gbp-buildpackage; doesn't find a valid upstream tarball it will create one by looking at the tag matching the upstream version. To change this behaviour see the option. @@ -26,7 +26,7 @@ Once you're satisfied with the build and want to do a release you commit all your changes and issue: -&git-buildpackage; +&gbp-buildpackage; This will again build the debian package and tag the final result after extracting the current version from the changelog. If you want &gpg; signed @@ -38,9 +38,9 @@ Using a separate build dir Tools like &svn-buildpackage; use a separate build-area. To achieve a similar behaviour - with &git-buildpackage; use the option: + with &gbp-buildpackage; use the option: -&git-buildpackage; =../build-area/ +&gbp-buildpackage; =../build-area/ This will export the head of the ecurrent branch to ../build-area/package-version, build the @@ -48,11 +48,11 @@ to export any treeish object, here are some examples: -&git-buildpackage; =../build-area =debian/0.4.3 -&git-buildpackage; =../build-area =etch -&git-buildpackage; =../build-area =8caed309653d69b7ab440e3d35abc090eb4c6697 -&git-buildpackage; =../build-area =INDEX -&git-buildpackage; =../build-area =WC +&gbp-buildpackage; =../build-area =debian/0.4.3 +&gbp-buildpackage; =../build-area =etch +&gbp-buildpackage; =../build-area =8caed309653d69b7ab440e3d35abc090eb4c6697 +&gbp-buildpackage; =../build-area =INDEX +&gbp-buildpackage; =../build-area =WC The special argument INDEX exports the state of the current index which can be used to include staged but uncommitted @@ -67,7 +67,7 @@ export-dir=../build-area # to use the same build area for all packages use an absolute path: #export-dir=/home/debian-packages/build-area - &git-buildpackage; will cleanup the build-area after a successful build. If + &gbp-buildpackage; will cleanup the build-area after a successful build. If you want to keep the build tree use --git-no-purge. @@ -85,7 +85,7 @@ export-dir=../build-area Running lintian - &git-buildpackage; exports several variables into the + &gbp-buildpackage; exports several variables into the 's environment (for details see the ). To invoke &lintian; we need to tell it where to find the changes file: @@ -102,7 +102,7 @@ export-dir=../build-area Pushing into a remote repository If you want to push your changes automatically after a successful build and tag - you can use &git-buildpackage;'s posttag hook. A very simple invocation would look like this: + you can use &gbp-buildpackage;'s posttag hook. A very simple invocation would look like this: git-buildpackage ="git push && git push --tags" @@ -153,7 +153,7 @@ echo "done." Running postexport hook - &git-buildpackage; exports several variables into the + &gbp-buildpackage; exports several variables into the 's environment (for details see the ). The motivation for the postexport action is to allow further adjustment of diff --git a/docs/chapters/cfgfile.sgml b/docs/chapters/cfgfile.sgml index 1cbe0b7..e9c6607 100644 --- a/docs/chapters/cfgfile.sgml +++ b/docs/chapters/cfgfile.sgml @@ -27,27 +27,27 @@ [DEFAULT] - Options in this section apply to &git-buildpackage;, - &git-import-orig;, &git-import-dsc; and &git-dch;. + Options in this section apply to &gbp-buildpackage;, + &gbp-import-orig;, &gbp-import-dsc; and &gbp-dch;. [git-buildpackage] - Options in this section apply to &git-buildpackage; only and override options from the + Options in this section apply to &gbp-buildpackage; only and override options from the [DEFAULT] section. [git-import-orig] - Options in this section apply to &git-import-orig; only and override options from the + Options in this section apply to &gbp-import-orig; only and override options from the [DEFAULT] section. [git-import-dsc] - Options in this section apply to &git-import-dsc; only and override options from the + Options in this section apply to &gbp-import-dsc; only and override options from the [DEFAULT] section. [git-dch] - Options in this section apply to &git-dch; only and override options from the + Options in this section apply to &gbp-dch; only and override options from the [DEFAULT] section. @@ -62,7 +62,7 @@ =dfsgfree - in the config file. In the special case of &git-buildpackage; the stripped + in the config file. In the special case of &gbp-buildpackage; the stripped prefix is not '--' but '--git-'. Here's a more complete example: diff --git a/docs/chapters/import.sgml b/docs/chapters/import.sgml index 6d41421..ddb3871 100644 --- a/docs/chapters/import.sgml +++ b/docs/chapters/import.sgml @@ -5,7 +5,7 @@ Importing already existing &debian; packages Importing an already exsting debian package into a git repository is as easy as: -&git-import-dsc; package_0.1-1.dsc +&gbp-import-dsc; package_0.1-1.dsc This will create a new git repository named after the imported package, put the upstream sources onto the and the @@ -26,15 +26,15 @@ &git; repository and just continue with the same command: cd package/ -&git-import-dsc; package_0.1-2.dsc -&git-import-dsc; package_0.1-3.dsc -&git-import-dsc; package_0.2-1.dsc +&gbp-import-dsc; package_0.1-2.dsc +&gbp-import-dsc; package_0.1-3.dsc +&gbp-import-dsc; package_0.2-1.dsc -Or you can import all versions at once using &git-import-dscs;: +Or you can import all versions at once using &gbp-import-dscs;: -&git-import-dscs; /path/to/history/package_*.dsc +&gbp-import-dscs; /path/to/history/package_*.dsc This will create a &git; repository if necessary and import all versions sorted by version number. @@ -46,9 +46,9 @@ by version number. Change into your git repository (which can be empty), make sure it has all local modifications committed and run either of: -&git-import-orig; /path/to/package_0.2.orig.tar.gz -&git-import-orig; /path/to/package_0.2.tar.bz2 -&git-import-orig; /path/to/package-0.2/ +&gbp-import-orig; /path/to/package_0.2.orig.tar.gz +&gbp-import-orig; /path/to/package_0.2.tar.bz2 +&gbp-import-orig; /path/to/package-0.2/ This puts the upstream souces onto the and tags them accordingly (the default tag format is @@ -59,7 +59,7 @@ by version number. options. You can also filter out content you don't want imported: -&git-import-orig; ='CVS/*' /path/to/package_0.2.orig.tar.gz +&gbp-import-orig; ='CVS/*' /path/to/package_0.2.orig.tar.gz The option can be used multiple times for more complex filtering. @@ -74,7 +74,7 @@ by version number. (orig.tar.gz) from &git; you should also specify the option. This is recommended. - To customize the commit message used by &git-import-orig; use + To customize the commit message used by &gbp-import-orig; use the option. This string is a standard python format string, into which the version variable is interpolated. (i.e., @@ -86,8 +86,8 @@ by version number. Converting an existing &git; repository - If the &git; repository wasn't created with &git-import-dsc; you have to tell - &git-buildpackage; and friends where to find the upstream sources. + If the &git; repository wasn't created with &gbp-import-dsc; you have to tell + &gbp-buildpackage; and friends where to find the upstream sources. Upstream sources on a branch @@ -99,7 +99,7 @@ by version number. &gitcmd; branch upstream theupstream-branch &gitcmd; branch theupstream-branch - or you can tell &git-buildpackage; the name of the branch to use as + or you can tell &gbp-buildpackage; the name of the branch to use as : cat <<EOF > .git/gbp.conf @@ -108,7 +108,7 @@ by version number. upstream-branch=theupstream-branch EOF - If you then use &git-import-orig; to import new upstream sources, they will + If you then use &gbp-import-orig; to import new upstream sources, they will from now on end up on theupstream-branch and merged to the . @@ -131,12 +131,12 @@ EOF There's currently no easy way to create the if you never had the upstream sources - as a single commit. Using &git-import-orig; on such repositories might lead + as a single commit. Using &gbp-import-orig; on such repositories might lead to unexpected merge results. In order to fix this you can prepend the upstream sources as a single commit to your tree using &git;'s grafts. Afterwards you - can simply create a branch as explained above and &git-import-orig; will + can simply create a branch as explained above and &gbp-import-orig; will work as expected. Alternatively, if you are only importing source from original tarballs (for instance when converting from a Subversion repository where the @@ -173,7 +173,7 @@ EOF Then you import the upstream sources, branch off the branch and add the debian files (e.g. via dh_make): -&git-import-orig; 0.1 ../package-0.1.tar.gz +&gbp-import-orig; 0.1 ../package-0.1.tar.gz dh_make That's it, you're done. If you want to publish you're new repository you can use &gbp-create-remote-repo;. @@ -194,7 +194,7 @@ EOF - &git-buildpackage; will by default create an upstream tarball for you. By default it will + &gbp-buildpackage; will by default create an upstream tarball for you. By default it will be created from the tag name given by the option. You can customize it's value via the configuration variable. @@ -211,7 +211,7 @@ upstream-tag = v%(version)s version will be replaced with the upstream version number as read from debian/changelog. - If you're using &pristine-tar; you can make &git-buildpackage commit the tarball back to the + If you're using &pristine-tar; you can make &gbp-buildpackage commit the tarball back to the pristine-tar branch by using the option. @@ -221,10 +221,10 @@ upstream-tag = v%(version)s If you want to track upstream's git but continue to import the upstream tarballs, e.g. to make sure the tarball uploaded to &debian; has the same checksum as upstream's you can use the option - when importing new tarballs with &git-import-orig;. Assuming you have the upstream source in your + when importing new tarballs with &gbp-import-orig;. Assuming you have the upstream source in your repository with a tag v0.0.1 you can use: - &git-import-orig; --upstream-vcs-tag=v0.0.1 foo_0.0.1.orig.tar.gz + &gbp-import-orig; --upstream-vcs-tag=v0.0.1 foo_0.0.1.orig.tar.gz to add upstream's tag as additional parent to the merge commit. See #664771 for more details. diff --git a/docs/chapters/intro.sgml b/docs/chapters/intro.sgml index 3fdf1f6..410a9e3 100644 --- a/docs/chapters/intro.sgml +++ b/docs/chapters/intro.sgml @@ -1,7 +1,7 @@ Introduction - Welcome to &git-buildpackage;, a system that integrates the + Welcome to &gbp-buildpackage;, a system that integrates the Debian package build system with Git. The current version of this manual can be found at here. @@ -29,7 +29,7 @@ Repository Layout and Terminology The only requirement on the repository layout for using - &git-buildpackage; and friends is, that the branch the debian work is + &gbp-buildpackage; and friends is, that the branch the debian work is being done on is different from the branch the upstream sources are being maintained on (this, of course, has no meaning for Debian native packages). This is necessary to be able to build upstream tarballs and @@ -70,7 +70,7 @@ You're completely free to pick any repository layout and the branch names above are only - &git-buildpackage;'s defaults. They can be changed at any point in time + &gbp-buildpackage;'s defaults. They can be changed at any point in time and you can work with an arbitrary number of branches. For example branches like nmu, bpo or stable might @@ -78,13 +78,13 @@ and branches like dfsg_free or snapshots might become your - it doesn't matter if these branches - are maintained with &git-import-orig; or not. + are maintained with &gbp-import-orig; or not. Since Git-Buildpackage only works with local &git;-repositories you have to use git-push in order to publish your changes to remote repositories like git.debian.org, this can also be - automized with &git-buildpackage;'s + automized with &gbp-buildpackage;'s hook. @@ -94,24 +94,24 @@ A typical, simple workflow consists of the following steps: - Import a new Debian package via &git-import-dsc;. This + Import a new Debian package via &gbp-import-dsc;. This imports the &debian; Package on the and the upstream sources on the . Develop, test, commit changes. During this time you can - always build the package with &git-buildpackage;. In case you have + always build the package with &gbp-buildpackage;. In case you have uncommitted changes in your source tree you can use the option. Optionally you can create the Debian changelog entries - using &git-dch; and create snapshot releases for testing using its + using &gbp-dch; and create snapshot releases for testing using its option. Once satisfied you can build the final package with - &git-buildpackage; . This additionally + &gbp-buildpackage; . This additionally creates a tag within &git; so you can switch back to that version later at any time. The format of the tags can be specified, tags can be &gpg; signed. When a new upstream version is released and upstream - isn't using &git; you can import the new version via &git-import-orig; - onto the . &git-import-orig; will + isn't using &git; you can import the new version via &gbp-import-orig; + onto the . &gbp-import-orig; will by default try to merge the new upstream version onto the . You can skip the merge with . After resolving any potential conflicts diff --git a/docs/chapters/releases.sgml b/docs/chapters/releases.sgml index d5cf087..6f00995 100644 --- a/docs/chapters/releases.sgml +++ b/docs/chapters/releases.sgml @@ -3,7 +3,7 @@ When branching and merging frequently, the different Debian changelog entries on the different branches tend to get into the way of the automatic merge and the the merge fails - leaving the (pathological) merge to the - committer. In order to avoid this &git-dch; offers a way for creating + committer. In order to avoid this &gbp-dch; offers a way for creating changelog entries from &git; commits before doing a release or anytime between releases. @@ -12,7 +12,7 @@ debian/changelog at all. Then, when done, do: -&git-dch; +&gbp-dch; This will look up the latest released version in the changelog, increment the version in the &debian; changelog, generate changelog @@ -23,7 +23,7 @@ But what if you want to have an (unreleased) snapshot for intermediate testing: -&git-dch; +&gbp-dch; will generate a snapshot release with a specially crafted version number and a warning in the changelog that this is a snapshort release: @@ -37,22 +37,22 @@ git-buildpackage (0.3.7~1.gbp470ce2) UNRELEASED; urgency=low During subsequent calls with this version number will continue to increase. Since the snapshot banners contains the - commit id of the current branch head, &git-dch; can figure out what to + commit id of the current branch head, &gbp-dch; can figure out what to append to the changelog by itself: -&git-dch; +&gbp-dch; will fetch the commit id and add changelog entries from that point to the current HEAD - again auto incrementing the version number. If you don't want to start at that commit id, you can specify any id or tag with: -&git-dch; =e76a6a180a57701ae4ae381f74523cacb3152780 +&gbp-dch; =e76a6a180a57701ae4ae381f74523cacb3152780 - After testing you can remove the snapshot header by a final &git-dch; call: + After testing you can remove the snapshot header by a final &gbp-dch; call: -&git-dch; =HEAD +&gbp-dch; =HEAD This will add no further entries but simply remove the specially crafted @@ -66,10 +66,10 @@ git-buildpackage (0.3.7~1.gbp470ce2) UNRELEASED; urgency=low can give any python expression that evaluates to a positive integer to calculate the new snapshot number: -&git-dch; =1 -&git-dch; ='snapshot + 2' -&git-dch; ='os.popen("git-log --pretty=oneline | wc -l").readlines()[0]' -&git-dch; =`git-log --pretty=oneline debian/0.3.3 | wc -l` +&gbp-dch; =1 +&gbp-dch; ='snapshot + 2' +&gbp-dch; ='os.popen("git-log --pretty=oneline | wc -l").readlines()[0]' +&gbp-dch; =`git-log --pretty=oneline debian/0.3.3 | wc -l` You can also add the snapshot-number calculation to gbp.conf: @@ -129,7 +129,7 @@ To only include the short description in the changelog and skip the body use: Git-Dch: Short -The latter only takes effect when running &git-dch; with the +The latter only takes effect when running &gbp-dch; with the option, since including only the short description is the default. @@ -144,7 +144,7 @@ Cl2vcs for how this looks. The inclusion of the commit id can be done automatically -via &git-dch;'s option. Using +via &gbp-dch;'s option. Using =7 would change the above example to: * [571bfd4] New upstream version (Closes: #1000) - thanks to cool upstream diff --git a/docs/chapters/special.sgml b/docs/chapters/special.sgml index 653f0ae..9c8aa64 100644 --- a/docs/chapters/special.sgml +++ b/docs/chapters/special.sgml @@ -18,7 +18,7 @@ master): -&git-import-orig; --no-merge /path/to/nondfsg-clean-package_10.4.orig.tar.gz +&gbp-import-orig; --no-merge /path/to/nondfsg-clean-package_10.4.orig.tar.gz &gitcmd; 10.4 @@ -50,11 +50,11 @@ cleanup-script.sh &gitcmd; nmu master - To import an NMU change into the git repository and use &git-import-dsc;: + To import an NMU change into the git repository and use &gbp-import-dsc;: &gitcmd; checkout master -&git-import-dsc; =nmu /path/to/package_1.0-1nmu0.dsc +&gbp-import-dsc; =nmu /path/to/package_1.0-1nmu0.dsc This will import the NMU onto the branched named nmu @@ -96,7 +96,7 @@ builder = /usr/bin/git-pbuilder sid distribution. If you want to build for another distribution pass this in the DIST environment variable. - Invoking &git-buildpackage; will now invoke &pdebuildcmd; by + Invoking &gbp-buildpackage; will now invoke &pdebuildcmd; by default and all additional command line arguments are passed to dpkg-buildpackage. If you want to use debuild again (without modifying @@ -106,7 +106,7 @@ builder = /usr/bin/git-pbuilder Furthermore, if you don't want this for all your invocations of - &git-buildpackage; you can use .git/gbp.conf in + &gbp-buildpackage; you can use .git/gbp.conf in one of your &git; repositories instead of ~/.gbp.conf. -- cgit v1.2.3