X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=dgit-maint-debrebase.7.pod;h=b3700a467e56463c302cf0173b0673865650a694;hb=193cfa37a544a2c44f9252b83da54ca1af01c01f;hp=b91ed1648ea676355c3727c7fcd327ea2b7bf375;hpb=9e94228f893936a65dea1a05758e523dc7e7d22f;p=dgit.git
diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod
index b91ed164..b3700a46 100644
--- a/dgit-maint-debrebase.7.pod
+++ b/dgit-maint-debrebase.7.pod
@@ -134,6 +134,32 @@ using git-diff(1) to compare the imported tarball to the release tag.
=back
+=head3 Using untagged upstream commits
+
+=over 4
+
+Sometimes upstream does not tag their releases, or you want to package
+an unreleased git snapshot. In such a case you can create your own
+upstream release tag, of the form BI, where I is
+the upstream version you plan to put in I. The
+B prefix ensures that your tag will not clash with any tags
+upstream later creates.
+
+For example, suppose that the latest upstream release is 1.2.2 and you
+want to package git commit ab34c21 which was made on 2013-12-11. A
+common convention is to use the upstream version number
+1.2.2+git20131211.ab34c21 and so you could use
+
+=over 4
+
+ % git tag -s upstream/1.2.2+git20131211.ab34c21 ab34c21
+
+=back
+
+to obtain a release tag, and then proceed as above.
+
+=back
+
=head2 When upstream releases only tarballs
Because we want to work in git, we need a virtual upstream branch with
@@ -145,64 +171,66 @@ begin
% mkdir foo
% cd foo
% git init
+ % git checkout -b upstream
+ % gbp import-orig \
+ --upstream-branch=upstream --debian-branch=master \
+ --upstream-tag='upstream/%(version)s' \
+ --sign-tags --no-pristine-tar \
+ ../foo_1.2.2.orig.tar.xz
+ % git branch -f upstream
=back
-Now create I:
+This should leave you on the master branch. Next, our upstream branch
+cannot be pushed to B, but since we will need it whenever
+we import a new upstream version, we must push it somewhere. The
+usual choice is B:
+
+=over 4
+
+ % git remote add -f origin salsa.debian.org:Debian/foo.git
+ % git push --follow-tags -u origin master upstream
+
+=back
+
+You are now ready to proceed as above, making commits to the
+I directory and to the upstream source. As above, for
+technical reasons, B In other words, make a commit introducing I before
+patching the upstream source.
+
+A convenient way to ensure this requirement is satisfied is to start
+by creating I:
=over 4
[DEFAULT]
upstream-branch = upstream
debian-branch = master
- upstream-tag = %(version)s
+ upstream-tag = upstream/%(version)s
sign-tags = True
pristine-tar = False
pristine-tar-commit = False
[import-orig]
- merge-mode = merge
+ merge = False
=back
-gbp-import-orig(1) requires a pre-existing upstream branch:
+and commit that:
=over 4
% git add debian/gbp.conf && git commit -m "create gbp.conf"
- % git checkout --orphan upstream
- % git rm -rf .
- % git commit --allow-empty -m "initial, empty branch for upstream source"
- % git checkout -f master
=back
-Then we can import the upstream version:
-
-=over 4
-
- % gbp import-orig --merge-mode=replace ../foo_1.2.2.orig.tar.xz
-
-=back
-
-Our upstream branch cannot be pushed to B, but since we
-will need it whenever we import a new upstream version, we must push
-it somewhere. The usual choice is B:
-
-=over 4
-
- % git remote add -f origin salsa.debian.org:Debian/foo.git
- % git push --follow-tags -u origin master upstream
-
-=back
-
-You are now ready to proceed as above, making commits to the
-I directory and to the upstream source. As above, for
-technical reasons, B In other words, make a commit introducing I before
-patching the upstream source.
+Note that we couldn't create I before now for the
+same technical reasons which require our first commit to introduce
+I without patching the upstream source. That's why we had to
+pass a lot of options to our first call to gbp-import-orig(1).
=head1 CONVERTING AN EXISTING PACKAGE
@@ -327,10 +355,14 @@ release, and importing that release using git-debrebase(1).
=over 4
- % git remote update
+ % git fetch --tags upstream
=back
+If you want to package an untagged upstream commit (because upstream
+does not tag releases or because you want to package an upstream
+development snapshot), see "Using untagged upstream commits" above.
+
=head3 When upstream releases only tarballs
You will need the I from "When upstream releases only
@@ -342,7 +374,7 @@ Then, either
=over 4
- % gbp import-orig --no-merge ../foo_1.2.3.orig.tar.xz
+ % gbp import-orig ../foo_1.2.3.orig.tar.xz
=back
@@ -350,7 +382,7 @@ or if you have a working watch file
=over 4
- % gbp import-orig --no-merge --uscan
+ % gbp import-orig --uscan
=back
@@ -375,9 +407,10 @@ release:
=back
-Pass I<--stat> just to see the list of changed files, which is useful
-to determine whether there are any new or deleted files that may need
-accounting for in your copyright file.
+Also, diff with I<--name-status> and I<--diff-filter=ADR> to see
+just the list of added or removed files, which is useful to determine
+whether there are any new or deleted files that may need accounting
+for in your copyright file.
If you obtained a tarball from upstream, you are ready to try a build.
If you merged a git tag from upstream, you will first need to generate
@@ -453,6 +486,10 @@ fast-forwarding from the history on B. In such cases you
will have to pass I<--overwrite> to dgit. git-debrebase will normally
tell you if this will be needed.
+If you want to upload with git-debpush(1), for the first upload you
+should pass the B<--quilt=linear> quilt mode option (see
+git-debpush(1)).
+
Right before uploading, if you did not just already do so, you might
want to have git-debrebase(1) shuffle your branch such that the Debian
delta queue appears right at the tip of the branch you will push: