git-merge(1), preserving all information about divergent development
that was later brought together.
-If you prefer linear histories, see dgit-maint-rebase(7).
-
=item
Maintaining convenient and powerful git workflows takes priority over
=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
-
=head1 INITIAL DEBIANISATION
-=head2 When upstream tags releases in git and releases identical tarballs
-
-Ideally upstream would make git tags, and tarball releases, which are
-completely identical to each other. If this is the case then you can
-use the upstream tarballs directly.
-
-If you're not sure, use the procedure below under "When upstream
-releases only tarballs" only with a different upstream tag name. Then
-use git diff to check that there are no differences.
+This section explains how to start using this workflow with a new
+package. It should be skipped when converting an existing package to
+this workflow.
=head2 When upstream tags releases in git
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)).
+=head3 Verifying upstream's tarball releases
+
+=over 4
+
+It can be a good idea to compare upstream's released tarballs with the
+release tags, at least for the first upload of the package. If they
+are different, you might need to add some additional steps to your
+I<debian/rules>, such as running autotools.
+
+A convenient way to perform this check is to import the tarball as
+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-deborig(1).
+
+=back
+
=head2 When upstream releases only tarballs
We need a virtual upstream branch with virtual release tags.
=back
+=head1 CONVERTING AN EXISTING PACKAGE
+
+This section explains how to convert an existing Debian package to
+this workflow. It should be skipped when debianising a new package.
+
+=head2 No existing git history
+
+=over 4
+
+ % dgit clone foo
+ % cd foo
+ % git remote add -f upstream https://some.upstream/foo.git
+
+=back
+
+=head2 Existing git history using another workflow
+
+First, dump any existing patch queue:
+
+=over 4
+
+ % git rm -rf debian/patches
+ % git commit -m "drop existing quilt patch queue"
+
+=back
+
+Then make new upstream tags available:
+
+=over 4
+
+ % git remote add -f upstream https://some.upstream/foo.git
+
+=back
+
+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.
+
+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 first dgit push will require I<--overwrite>.
+
=head1 SOURCE PACKAGE CONFIGURATION
=head2 debian/source/options
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
changes to the upstream source:
=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 ../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
-Either
+You will need the I<debian/gbp.conf> from "When upstream releases only
+tarballs", above.
+
+Then, either
=over 4
determine whether it would be legally dangerous for the non-free
material to be publicly accessible in the git history on
B<dgit-repos>.
+
If it would be dangerous, there is a big problem;
in this case please consult your archive administrators
(for Debian this is the dgit administrator dgit-owner@debian.org
~ianmdlvl / dgit.git / blobdiff