you make, for Debian, to the upstream parts of the package - as a
series of commits.
-[usps slide]
+[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.
+
+As you make new commits, you may make commits to upstream files, and
+commits to packaging, in any order. So you can just git-cherry-pick
+from upstream. You can make fixup commits, and use the git-rebase
+autosquash syntax to have them automatically folded in by the next
+rebase. If you wish, you may make "mixed" commits containing both
+changes to upstream files and changes to packaging files.
+
+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
+order to edit the delta queue. Some tools have specific functions for
+cherry-pick, but with none of them you can just cherry pick or git-am
+onto your current HEAD.
+
+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.
+
+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.
+
+[usp slide 2]
+
+Unlike with gbp pq and git-dpm, there is no need to ever switch
+branches. git-debrebase only uses one branch to handle all for your
+Debian work. (Usually you will have an upstream branch as well of
+course, and if you are working in multiple Debian releases, backports
+for example, you will have branches for those.)
+
+Yowr working tree is always immediately buildable with
+dpkg-buildpackage. 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.
+
+Because git-debrebase treats the quilt patches in debian/patches/ as
+an output, and handles them entirely automatically, your tree is never
+dirtied by the generation of patches. And you never need to read any
+diffs of diffs.
+
+[usp slide 3]
+
+And, my last slide of non-bugs:
+
+git-blame, and git-log on a file, work entirely 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.
+
+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
+file in the debian directory, you will see a correct reporting of
+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 you will
+still get trouble if you make changes in git which 3.0 quilt cannot
+represent).
+
+When you use git-debrebase with 3.0 quilt, the quilt output is always
+perfect and pretty, just as other people consuming .dscs have come to
+expect.
+
+And finally: of course, git-debrebase is compatible with dgit. You do
+not need to pass any quilt mode option. And, you always can upload
+right away. All necessary bureaucracy is done automatically by dgit
+push-source.
-You can git commit -m fixup! and git commit -m squash!
-| always, unlike gbp pq
-
-You can git-am and git-cherry-pick upstream patches
-| always, unlike gbp pq
-
-You may make mixed commits touching debian/ and upstream files
-| unlike any other Debian delta queue workflow
-
-There is no need to ever use quilt
-
-There is no in-tree metadata to get out of date
-| unlike git-dpm
-
-Your working tree is never dirtied by your tools
-| unlike gbp pq
-
-There is no need to switch branches or switch views
-| unlike gbp pq
-
-Your working tree is always buildable, in-tree, with dpkg-buildpackage, debuild, git-buildpackage, etc.
-| unlike gbp pq
-
-You can mostly ignore the `3.0 (quilt)' source package format
-
-During development you do not need any orig tarballs;
-they are only needed when actually uploading to Debian.
-
-The Debian delta queue is managed using a standard git-rebase workflow.
-
-git-log and git-blame on upstream files show the real upstream history
-followed by your delta queue commits, as expected.
-
-git-log and git-blame on debian/ files show your packaging history.
-
-You don't need to edit diffs, or read diffs of diffs.
-Instead, you edit commits the standard git way.
~ijackson / talk-2018-dc18-gdr.git / commitdiff