-Hi. I'm here to plug dgit, which is a tool (and infrastructure) for
-treating the Debian archive like a git remote.
+==== overview slide
+>
+> dgit - treat the archive as a git remote
+>
+> COLOUR 1 using dgit on other contributors' packages
+>
+> COLOUR 2 dgit for the Debian package maintainer
+>
+> Miscellany
+
+
+Hi. I'm here to plug dgit, which is a system for treating the Debian
+archive like a git remote.
I'm going to talk for about 35 minutess and then I'll take questions.
-----------------------------------------
When we work on Debian we take on different roles. The biggest
difference is between the maintainer (or maintainers) of a package,
I'm going to start by presenting dgit from the point of view of
everyone else: NMUers, sponsorship, teams doing cross-archive work
like transitions and reproducible builds, bug squashers, downstreams,
-users, and so on.
+users, and so on. Maintainers, please be patient - I'll get to you.
-The point of dgit is that it lets you treat the archive as if it were
-a git repository.
+==== manpage slide
+
+The point of dgit is that it lets everyone treat the archive as if it
+were a git repository.
You can dgit clone any package, in any suite in the archive (so, for
example, sid or experimental) and you will get a git tree which is
You can then work on the package in git, the way you would work in git
with any other project. In particular, you can:
- * commit on your local branch
+ * commit locally
* cherry pick changes from other branches
* git reset, git clean
* git rebase -i to polish a more complex set of changes into
a patch queue
If you want so share your work-in-progress with others, you can git
-push your branch anywhere where they will be able to fetch it.
+push your branch anywhere suitable, so they can fetch it.
If you have the right authority you can also dgit push, to upload
(after doing a build).
+==== structure slide
+> include git-dpm, git, etc.
+
dgit is not a replacement for existing git packaging tools; it's
intended to complement them. So (unlike git-dpm) dgit does not define
a git history structure, and (unlike git-buildpackage) it does not
The dgit history structure is up to the maintainer. If you are doing
a straightforward NMU you should produce a well-structured linear
-sequence of commits, as you would for any git upstream. If the
-package is using a quilty source format, you should not touch
-debian/patches; dgit will take care of updating the quilt patch stack.
+sequence of commits, as you would for any git upstream. If the source
+package is `3.0 (quilt)', you should not touch debian/patches; dgit
+will take care of that for you.
Unless the maintainer uses dgit, the history you see in dgit will not
be the maintainer's history. This is because maintainers' git
-branches are often not identical to the source packages in the
-archive.
+branches often differ from the source packages in the archive.
-And, when dgit has to synthesise a git history because the maintainer
-is not using dgit, the history you see in dgit will have a very basic
-branch and commit structure, rather than representing the package's
-actual history.
+So dgit may have to synthesise a git history. The history you see in
+dgit will then have a very basic branch and commit structure, rather
+than representing the package's actual history.
-----------------------------------------
+==== history comparison slide
+> you use dgit
+> you don't use dgit
Which brings me onto the other side of this talk: dgit for
maintainers.
-For the reasons I've explained, other dgit users would like you to use
-dgit for your maintainer uploads. They will then be able to see, and
-directly work with, your own history.
+For the reasons I've explained, downstream dgit users would like you
+to use dgit for your maintainer uploads. They will then be able to
+see, and directly work with, your own history.
But it's in your own interests, too:
you are uploading is exactly the same as your git HEAD. This can
save you some dsc-based checks.
-And, of course, non-maintainer dgit users will thank you.
+And, as I say, non-maintainer dgit users will thank you.
+==== structure slide
+> with push requirement clearer
+
dgit push imposes only two requirements on your git trees. These stem
-directly from the need for the dgit view of package to be identical to
-the package as found in the archive. The dgit view of every package
-needs to uniformly and directly useable.
+directly from dgit's design goals.
-The first, and most important, requirement is that your git tree is
-identical to the unpacked source package. (Technically, in the case
-of a `3.0 (quilt)' package, it is what is sometimes called a `patches
-applied packaging branch without .pc'.)
+The most important requirement is that your git tree is identical to
+the unpacked source package. (Technically, in the case of a `3.0
+(quilt)' package, it is what is sometimes called a `patches applied
+packaging branch without .pc'.)
For all native packages, and for users of git-dpm and raw git, this is
already the interchange format. These maintainers can start using
dgit right away. Please do!
-For git-buildpackage users, things are a bit more complicated. I'm
-told that gbp pq can be used to generate a patches-applied branch, and
-that some users prefer to use that as the interchange git branch.
+For those using git-buildpackage with `3.0 (quilt)', things are a bit
+more complicated. I'm told that gbp pq can be used to generate a
+patches-applied branch, and that some users prefer to use that as the
+interchange git branch. I'm talking to the git-buildpackage
+maintainers about gbp integration.
-I mentioned that there were two requirements. The other is simply
-that the dgit branch (one for each suite) is fast-forwarding. So if
-you (or your workflow tool) generated a rebasing branch, you may need
-to do something like
+The other requirement of dgit is simply that the dgit branches are
+fast-forwarding. So if your tools have made a rebasing branch, you
+may need to do something like
git merge -s ours dgit/sid
-before pushing. I'm intending to provide some rather more cookied
+before pushing. I'm intending to provide some rather more cooked
way to do this but I have decided the exact shape yet.
-----------------------------------------
+==== structure diagram
+>
There are a few other things I ought to cover, since they often come
-up:
+up. They're are relevant to maintainers and others:
+
+
+DMs currently need to email a signed copy of their ssh key, in order
+to be able to push.
-The dgit view of the archive does not include the package upload
-history. It is possible to use git-import-dscs to produce a git
-branch representing the upload history, but dgit does not do this
-itself.
+The dgit view does not generally include the package upload history.
+git-import-dscs can produce a git branch representing the upload
+history, but dgit does do that itself.
-There is nothing stopping anyone from pushing such a branch to the
-archive with dgit push. But, it seems to me that the git history
-structure ought to up to the maintainer, and if the maintainer chooses
-to use dgit, normally the maintainers's existing git history is more
-useful and interesting.
+One could push such a branch to the archive with dgit push. But, it
+seems to me that the git history structure ought to up to the
+maintainer, and if the maintainer chooses to use dgit, the
+maintainers's existing git history is probably better.
-When using dgit, it is normally best to use one of dgit's build
-operations to build the package. This is mainly because most other
-build tools by default remove .gitignore when generating the source
-package. dgit requires that the source package and git tree are the
+It is normally best to use one of dgit's build operations to build for
+upload. This is mainly because most other tools remove .gitignore by
+default. dgit requires that the source package and git tree are the
same, so if your git tree has .gitignore in it, your source package
should too.
Some maintainers' source packages contain files not in their git
-branches: most commonly, autotools output. Because the point of dgit
-is to provide a git view of what's actually in the archive, this does
-not work with dgit.
-
-But nowadays most people seem to recommend that the package build
-should rerun autotools and regenerate these files, anyway. If you do
-this, then neither your git tree nor your source package contain the
-autotools output and all is well.
-
-Alternatively, you can commit the autotools output to git (and resolve
-any conflicts by simply rerunning autotools), or maintain a separate
-post-autotools git branch.
-
-
-
-
-
-The point, of course, of using
-
-
-
-
-
-
-
-
-
-
-
- defer talking about
-
-
+branches: most commonly, autotools output. This is not compatible
+with dgit's purpose, namely to provide a git view of what's actually
+in the archive.
+
+But nowadays most people recommend that the package build should
+always rerun autotools, anyway. If you do that, then neither your git
+tree nor your source package need contain the autotools output and all
+is well.
+
+Alternatively, you can commit the autotools output to git.
+
+
+==== Future plans slide
+> DELAYED uploads
+>
+> automatic sending of the NMU diff email
+>
+> source-only one step push
+>
+> use of the dgit git repo server (other branches and tags) for general
+> purpose work
+>
+> more assistance for use with raw git
+>
+> automatic tracking of uploads into the dgit suite branches
+>
+>
+> help needed
+>
+> better workflow documentation for integration with existing git tools
+>
+> better gbp integration
+>
+> sponsor queue
+
+
+I have a number of plans for the future, some of which I need help
+with. I don't have time I'm afraid to go through them now.
+
+Instead, I'm going to open the talk up to questions now.
~ijackson / talk-2015-debconf-dgit.git / commitdiff