maintain a useful git branch with the contents you need (for building
and uploading).
-It maintains your Debian delta queue - that is, that is, the changes
-you make, for Debian, to the upstream parts of the package - as a
-series of commits. It's primarily intended for Debian package
-maintainers, although you could use it outside of or alongside Debian.
+git-debrebase is mainly concerned with maintaining your Debian delta
+queue. That is, that is, the changes you make, for Debian, to the
+upstream parts of the package. Other tools tend to call this your
+"quilt patch series". But with git-debrebase there is no quilt, and
+you don't work with patches. Instead, there is a series of commits.
+So, we prefer the term "delta queue".
+
+It's primarily intended for Debian package maintainers, although you
+could use it outside of or alongside Debian.
git-debrebase does not deal with building at all. You use whatever
your existing build tools are.
Nor does git-debrebase deal with source packages or orig tarballs. It
does not do uploads. Of course when you actually upload to Debian you
-need to produce a source package; usually, this would be done
-automatically for you by dgit push-source.
+need to produce a source package. Getting a source package is, of
+course, as easy or easier than with other workflows. Usually, it is
+done automatically for you by dgit push-source, so you usually don't
+need to concern yourself with .dsc source packages even when uploading
+to Debian.
Of course you can share your git branch on a service like salsa,
without building or uploading.
===== usp slide 1
git-debrebase offers a standard git-rebase workflow, where you edit
-the whole package all together. The experience is very like using
-plain git-rebase to edit a topic branch. Delta queue editing can be
-done at any time, interleaved with packaging work.
+the whole of the source code for your package, including your changes
+to upstream files and your changes to packaging, all together.
+The experience is very like using plain git-rebase to edit a topic
+branch. Delta queue editing can be done at any time, interleaved with
+packaging work.
As far as I know there are no other tools that offer these features.
Both gbp pq and git-dpm require you to switch to a separate view in
Of course you can always directly edit the source if you use a plain
git merge workflow and non-quilt source package - for example, as
described in the dgit-maint-merge tutorial manpage. But of course
-that does not maintain the Debian delta as a broken-down series.
-Supporting you maintaining such a delta queue is what git-rebase is
-for.
+that does not maintain the Debian delta as a broken-down series;
+and in the source package such a merge based workflow squashes all the
+changes into a single debian-changes patch.
+
+So supporting you maintaining a delta queue - that is, a linear series
+of changes - is what git-rebase is for.
+
Also, unlike git-dpm and some other tools, git-debrebase has no
in-tree metadata, so it can't get out of date or be desynchronised,
switch branches. git-debrebase only uses one branch to handle all for
your Debian work.
-Of course usually you will have an upstream remote tracking branch as
+Of course usually you will have an upstream remote-tracking branch as
well. And if you are working in multiple Debian releases, backports
for example, you will have branches for those. But it's only one
branch for each line of Debian development, and no temporary branches
or alternative views.
-With git-debrebase, yowr working tree is always immediately buildable
-with dpkg-buildpackage (or whatever other build tool you prefer). And
-it is never made dirty by git-debrebase or any of the other tooling:
-Because your working tree always has the delta queue applied, it is
-never dirtied by patch application. Because there is no metadata, you
-can never get a metadata conflict.
+With git-debrebase, you can always immediately build binaries out of
+your working tree, with dpkg-buildpackage (or whatever other build
+tool you prefer). And your working tree is never made dirty by
+git-debrebase or any of the other tooling: Because your working tree
+always has the delta queue applied, it is never dirtied by patch
+application. Because there is no metadata, you can never get a
+metadata conflict.
Because git-debrebase treats the quilt patches in debian/patches/ as
an output, and handles them entirely automatically, your tree is never
properly. For example, if you do git-log on a file from upstream
which was changed in the Debian delta queue, git-log will show the
Debian delta queue commits, preceded by the upstream history.
+We'll show an example of this in the demo.
If you run git-blame you will see a correct indication of which
upstream and/or delta queue commits introduced each line. Or, for a
which commits in the package's packaging history introduced each line.
With git-debrebase, you never need to use the quilt program. You can
-mostly ignore the 3.0 quilt source format. Unfortunately it is not
-possible to paper over the cracks completely: you will still get
-trouble if you make changes in git which 3.0 quilt cannot represent.
+mostly ignore the 3.0 quilt source format.
+
+This is all really good for newbies. Particularly, for people from
+other sofware development communities who don't know about Debian.
+
+Unfortunately it is not possible to paper over the cracks completely:
+you will still get trouble if you make changes in git which 3.0 quilt
+cannot represent.
On the other hand, when you use git-debrebase with 3.0 quilt, the
generated 3.0 quilt source package is perfect pretty, with your delta
that's it as far as the code in git is concerned.
Of course if you are going to upload to the Debian archive you'll also
-have to make an orig tarball of the new upstream. There are tools
-like git-deborig to help with that.
+have to make an orig tarball of the new upstream. If you're using the
+workflow I've been describing so far, that's generally just a single
+call to git-deborig.
===== data model slide up to PM [5]
More common is a different kind of merge problem.
What happens if you one of your delta queue commits doesn't apply
-during the upstream rebase ?
+during the upstream rebase - that is, your patch does not apply to the
+new upstream source code ?
git-rebase users will have seen this kind of situation before.
git-rebase stops at the first commit which can't be applied in
The autogenerated special breakwater merge, and changelog entry, are
discarded, leaving you just where you were before. You've wasted no
-effort because everything you're throwing away was machine-made.
+effort because everything you're throwing away was machine-generated.
===== data model slide [5] AGAIN
~ijackson / talk-2018-dc18-gdr.git / commitdiff