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
+If you have an existing git history that you have pushed to an
+ordinary git server like B<salsa.debian.org>, we start with that. If
+you don't already have it locally, you'll need to clone it, and obtain
+the corresponding orig.tar from the archive:
+
+=over 4
+
+ % git clone salsa.debian.org:Debian/foo
+ % cd foo
+ % dgit setup-new-tree
+ % origtargz
+
+=back
+
+If you don't have any existing git history, or you have history only
+on the special B<dgit-repos> server, we start with B<dgit clone>:
=over 4
% dgit clone foo
% cd foo
+
+=back
+
+Then we make new upstream tags available:
+
+=over 4
+
% git remote add -f upstream https://some.upstream/foo.git
=back
-=head2 Existing git history using another workflow
+We now use a B<git debrebase convert-from-*> command to convert your
+existing history to the git-debrebase(5) data model. Which command
+you should use depends on some facts about your repository:
+
+=over 4
+
+=item (A) There is no delta queue.
-First, if you don't already have the git history locally, clone it,
-and obtain the corresponding orig.tar from the archive:
+If there do not exist any Debian patches, use
=over 4
- % git clone salsa.debian.org:Debian/foo
- % cd foo
- % origtargz
+ % git debrebase convert-from-gbp
=back
-If your tree is patches-unapplied, some conversion work is needed.
-You can use
+=item (B) There is a delta queue, and patches are unapplied.
+
+This is the standard git-buildpackage(1) workflow: there are Debian
+patches, but the upstream source is committed to git without those
+patches applied. Use
=over 4
- git debrebase convert-from-gbp
+ % git debrebase convert-from-gbp
=back
-Then make new upstream tags available:
+=item (C) There is a delta queue, and patches are applied.
+
+Use
=over 4
- % git remote add -f upstream https://some.upstream/foo.git
+ % git debrebase convert-from-dgit-view
=back
-Now you simply need to ensure that your git HEAD is dgit-compatible,
+=back
+
+Finally, you need to ensure that your git HEAD is dgit-compatible,
i.e., it is exactly what you would get if you deleted .git, invoked
B<dpkg-buildpackage -S>, and then unpacked the resultant source
package.
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 GIT CONFIGURATION
git-debrebase(1) does not yet support using B<git merge> to merge
=over 4
- % git debrebase new-upstream-v0 1.2.3
+ % git debrebase new-upstream 1.2.3
=back
=head1 BUILDING AND UPLOADING
You can use dpkg-buildpackage(1) for test builds. When you are ready
-to build for an upload, use B<dgit sbuild>.
+to build for an upload, use B<dgit sbuild>, B<dgit pbuilder> or B<dgit
+cowbuilder>.
Upload with B<dgit push> or B<dgit push-source>. Remember to pass
I<--new> if the package is new in the target suite.
=over 4
- % git debrebase launder
+ % git debrebase
% git rebase -i HEAD~5 # there are 4 Debian patches
=back
If you take this approach, you should be very careful not to start the
-rebase too early.
+rebase too early,
+including before the most recent pseudomerge.
+git-rebase without a base argument will often
+start the rebase too early,
+and should be avoided.
+Run git-debrebase instead.
+See also "ILLEGAL OPERATIONS" in git-debrebase(5).
=head1 SEE ALSO