This is the command line reference.
Please read the tutorial
-L<dgit-maint-debrebase(5)>.
+L<dgit-maint-debrebase(7)>.
For background, theory of operation,
and definitions see L<git-debrebase(5)>.
-You should read this manpage in conjunction with
+You should read this manpage in cojnunction with
L<git-debrebase(5)/TERMINOLOGY>,
which defines many important terms used here.
or be prececded by C<-->,
to distinguish them from options for git-debrebase.
+It is hazardous to use plain git-rebase on a git-debrebase branch,
+because git-rebase has a tendency to start the rebase
+too far back in history,
+and then drop important commits.
+Soo L<git-debrebase(5)/ILLEGAL OPERATIONS>
+
=item git-debrebase status
-Analyise the current branch,
-both in terms of its conents,
+Analyses the current branch,
+both in terms of its contents,
and the refs which are relevant to git-debrebase,
-and print a human-readable summary.
+and prints a human-readable summary.
Please do not attempt to parse the output;
it may be reformatted or reorganised in the future.
You should consider using B<conclude> instead,
because that launders the branch too.
-=item git-debrebase new-upstream-v0 <new-version> [<upstream-details>...]
+=item git-debrebase new-upstream <new-version> [<upstream-details>...]
Rebases the delta queue
onto a new upstream version. In detail:
the whole new upstream operation is aborted,
except for the laundering.
+<new-version>
+may be whole new Debian version, including revision,
+or just the upstream part,
+in which case -1 will be appended
+to make the new Debian version.
+
The <upstream-details> are, optionally, in order:
=over
=item <upstream-commit-ish>
The new upstream branch (or commit-ish).
-Default is C<upstream>.
+The default is to look for one of these tags, in this order:
+U vU upstream/U;
+where U is the new upstream version.
+(This is the same algorithm as L<git-deborig(1)>.)
It is a snag if the upstream contains a debian/ directory;
if forced to proceed,
L<git-archive(1)>, L<dgit(1)> and
L<gbp-import-orig(1)> may be able to help.
-This subcommand has -v0 in its name because we are not yet sure
-that its command line syntax is optimal.
-We may want to introduce an incompatible replacement syntax
-under the name C<new-upstream>.
-
=item git-debrebase make-patches [--quiet-would-amend]
Generate patches in debian/patches/
make-patches will fail with exit status 7,
and an error message.
(The message can be suppress with --quiet-would-amend.)
+If the problem is simply that
+the existing patches were not made by git-debrebase,
+using dgit quilt-fixup instead should succeed.
=item git-debrebase convert-from-gbp [<upstream-commit-ish>]
It is a snag if it is not an ancestor of HEAD,
or if the history between the upstream and HEAD
contains commits which make changes to upstream files.
+If it is not specified,
+the same algorithm is used as for git-debrebase new-upstream.
It is also a snag if the specified upstream
has a debian/ subdirectory.
but if this situation is true and expected,
forcing it is fine.
+git-debrebase will try to look for the dgit archive view
+of the most recent release,
+and if it finds it will make a pseduomerge so that
+your new git-debrebase view is appropriately fast forward.
+
The result is a well-formed git-debrebase interchange branch.
The result is also fast-forward from the gbp branch.
+It is a snag if the new branch looks like it will have diverged,
+just as for a laundering/unstitching call to git-debrebase;
+See L</Establish the current branch's ffq-prev>, below.
+
Note that it is dangerous not to know whether you are
dealing with a gbp patches-unappled branch containing quilt patches,
or a git-debrebase interchange branch.
Some troublesome things which git-debrebase encounters
are B<snag>s.
(The specific instances are discussed
-in the text for the relvant operation.)
+in the text for the relevant operation.)
When a snag is detected,
a message is printed to stderr containing the snag id