is synthesized by your local copy of dgit.
It is fast forwarding.
-Debian separates out the security updates, into C<debian-security>.
-Telling dgit C<debian,-security> means that it should include
-any updates available in C<debian-security>.
+Debian separates out the security updates, into C<*-security>.
+Telling dgit C<jessie,-security> means that it should include
+any updates available in C<jessie-security>.
+The comma notation is a request to dgit to track jessie,
+or jessie-security if there is an update for the package there.
(You can also dgit fetch in a tree that wasn't made by dgit clone.
If there's no C<debian/changelog>
But for many packages the real git history
does not exist,
or has not been published in a dgitish form.
-So yuu may find that the history is a rather short
+So you may find that the history is a rather short
history invented by dgit.
dgit histories often contain automatically-generated commits,
they may modify files which are also committed to git,
or leave outputs and teporary files not covered by C<.gitignore>.
-Kf you always commit,
+If you always commit,
you can use
=over 4
is to build the package for all the architectures you
have enabled.
You'll need a chroot for each of the secondary architectures.
-This iw somewhat tiresome,
+This is somewhat tiresome,
even though Debian has excellent tools for managing chroots.
C<sbuild-createchroot> from the sbuild package is a
good starting point.
your desperate last resort is to try
using the same version number
as the official package for your own package.
-(The verseion is controlled by C<debian/changelog> - see above,)
+(The version is controlled by C<debian/changelog> - see above).
This is not ideal because it makes it hard to tell what is installed,
-because it will mislead and confuse apt.
+and because it will mislead and confuse apt.
With the "same number" approach you may still get errors like