7 Sean Whitton and I are here to present a new git workflow tool for
8 Debian packaging. It's primarily intended for Debian package
9 maintainers. It's an alternative to gbp pq and to git-dpm.
11 Before I get tell you all about it I need to show where it fits into
12 the ecosystem of Debian package management software. On this slide we
13 have you, the maintainer, on the left. On the right we have the
16 You may have heard me plugging dgit once or twice. You should all use
17 dgit! dgit push publishes your git history so Debian's users can use
18 it! But, that's not actually what I am here to talk about today.
19 git-debrebase does not need dgit, and dgit does not need
22 git-debrebase is a tool to help manage your git branch containing the
23 Debian version of a package you maintain. git-debrebase helps you
24 maintain a useful git branch with the contents you need (for building
27 It maintains your Debian delta queue - that is, that is, the changes
28 you make, for Debian, to the upstream parts of the package - as a
33 You can git commit -m fixup! and git commit -m squash!
34 | always, unlike gbp pq
36 You can git-am and git-cherry-pick upstream patches
37 | always, unlike gbp pq
39 You may make mixed commits touching debian/ and upstream files
40 | unlike any other Debian delta queue workflow
42 There is no need to ever use quilt
44 There is no in-tree metadata to get out of date
47 Your working tree is never dirtied by your tools
50 There is no need to switch branches or switch views
53 Your working tree is always buildable, in-tree, with dpkg-buildpackage, debuild, git-buildpackage, etc.
56 You can mostly ignore the `3.0 (quilt)' source package format
58 During development you do not need any orig tarballs;
59 they are only needed when actually uploading to Debian.
61 The Debian delta queue is managed using a standard git-rebase workflow.
63 git-log and git-blame on upstream files show the real upstream history
64 followed by your delta queue commits, as expected.
66 git-log and git-blame on debian/ files show your packaging history.
68 You don't need to edit diffs, or read diffs of diffs.
69 Instead, you edit commits the standard git way.