is thought of as an output format.
For example, we don't spend time curating a series of quilt patches.
-However, the information such a series would contain is readily
+However,
+in straightforward cases,
+the information such a series would contain is readily
available from B<dgit-repos>.
=item
=back
-=head1 GIT CONFIGURATION
-
-Add the following to your ~/.gitconfig to teach git-archive(1) how to
-compress orig tarballs:
-
-=over 4
-
- [tar "tar.xz"]
- command = xz -c
- [tar "tar.gz"]
- command = gzip -c
-
-=back
+This workflow is less suitable for some packages.
+When the Debian delta contains multiple pieces which interact,
+or which you aren't going to be able to upstream soon,
+it might be preferable to
+maintain the delta as a rebasing patch series.
+For such a workflow see for example
+dgit-maint-gbp(7).
=head1 INITIAL DEBIANISATION
=back
-The final command detachs your master branch from the upstream remote,
+The final command detaches your master branch from the upstream remote,
so that git doesn't try to push anything there, or merge unreleased
upstream commits. If you want to maintain a copy of your packaging
branch on B<alioth.debian.org> in addition to B<dgit-repos>, you can
work with upstream tags rather than any branches, except when
forwarding patches (see FORWARDING PATCHES UPSTREAM, below).
-Finally, you need an orig tarball. Generate one with git-archive(1):
+Finally, you need an orig tarball:
=over 4
- % git archive -o ../foo_1.2.2.orig.tar.xz 1.2.2
+ % git deborig
=back
-If you are using the version 1.0 source package format, replace 'xz'
-with 'gz'.
+See git-deborig(1) if this fails.
This tarball is ephemeral and easily regenerated, so we don't commit
it anywhere (e.g. with tools like pristine-tar(1)).
described in the following section, using a different value for
'upstream-tag', and then use git-diff(1) to compare the imported
tarball to the release tag. If they are the same, you can use
-upstream's tarball instead of running git-archive(1).
+upstream's tarball instead of running git-deborig(1).
=back
=back
-Then we can import the upstream version:
+gbp-import-orig(1) requires a pre-existing upstream branch:
=over 4
% git add debian/gbp.conf && git commit -m "create gbp.conf"
- % gbp import-orig ../foo_1.2.2.orig.tar.xz
+ % 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
% dgit clone foo
% cd foo
+ % git remote add -f upstream https://some.upstream/foo.git
=back
=back
+=for dgit-test dpkg-source-ignores begin
+
Now you simply need to ensure that your git HEAD is dgit-compatible,
-i.e., it is exactly what you would get if you ran B<dpkg-buildpackage
--i\.git/ -I.git -S> and then unpacked the resultant source package.
+i.e., it is exactly what you would get if you ran
+B<dpkg-buildpackage -i'(?:^|/)\.git(?:/|$)' -I.git -S>
+and then unpacked the resultant source package.
+
+=for dgit-test dpkg-source-ignores end
To achieve this, you might need to delete
I<debian/source/local-options>. One way to have dgit check your
progress is to run B<dgit build-source>.
-The dgit push will require I<--overwrite>.
+The first dgit push will require I<--overwrite>.
=head1 SOURCE PACKAGE CONFIGURATION
You don't need to create this file if you are using the version 1.0
source package format.
-=head2 Sample text for README.source
+=head2 Sample text for debian/source/patch-header
-It is a good idea to explain how a user can obtain a break down of the
+It is a good idea to explain how a user can obtain a breakdown of the
changes to the upstream source:
=over 4
-The Debian packaging of foo is maintained using dgit. For the sake of
-an efficient workflow, Debian modifications to the upstream source are
-squashed into a single diff, rather than a series of quilt patches.
-To obtain a patch queue for package version 1.2.3-1:
+The Debian packaging of foo is maintained in git,
+using the merging workflow described in dgit-maint-merge(7).
+There isn't a patch queue that can be represented as a quilt series.
+
+A detailed breakdown of the changes is available from their
+canonical representation -
+git commits in the packaging repository.
+For example, to see the changes made by the Debian maintainer in the
+first upload of upstream version 1.2.3, you could use:
=over 4
- # apt-get install dgit
- % dgit clone foo
+ % git clone https://git.dgit.debian.org/foo
% cd foo
% git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian'
=back
-See dgit(1), dgit(7) and dgit-maint-merge(7) for more information.
+(If you have dgit, use `dgit clone foo`,
+rather than plain `git clone`.)
+
+A single combined diff, containing all the changes, follows.
=back
+Alternatively, this text could be added to README.source. However,
+this might distract from more important information present in the
+latter file.
+
=head1 BUILDING AND UPLOADING
Use B<dgit build>, B<dgit sbuild>, B<dgit build-source>, and B<dgit
=over 4
- % git archive -o ../foo_1.2.3.orig.tar.xz 1.2.3
% git merge 1.2.3
% dch -v1.2.3-1 New upstream release.
% git add debian/changelog && git commit -m changelog
+ % git deborig
=back
and you are ready to try a build.
-Again, if you are using the version 1.0 source package format, replace
-'xz' with 'gz'.
-
=head2 When upstream releases only tarballs
You will need the I<debian/gbp.conf> from "When upstream releases only
~ianmdlvl / dgit.git / blobdiff