--- /dev/null
+
+Hi. I'm here to plug dgit, which is a tool (and infrastructure) for
+treating the Debian archive something 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,
+working on their own package, and everyone else.
+
+I'm going to start by presenting dgit from the point of view of
+everyone else: NMUers, sponsorship, teams doing cross-archive work
+(eg, transitions, reproducible builds), bug squashers, and so on.
+
+
+The point of dgit is that it lets you 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
+exactly the same as dpkg-source -x.
+
+You can then work on the package in git, the way you would work in git
+with any other project. In particular:
+
+ * commit on your local branch
+ * cherry pick
+ * git reset, git clean
+ * git-rebase -i to polish your changes
+
+If you want so share your work-in-progress with others, you can git
+push the branch anywhere where they will be able to fetch it.
+
+If you are a DD (or a DM for the package) you can also dgit push the
+package. (Currently you still need to do a source package build.)
+
+
+Because dgit knows that your git tree is canonical, it can help you
+work around strangely behaved package clean targets: you can instruct
+dgit to use git clean rather than running the package's clean target.
+
+
+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
+define a branch structure. Nor does it require use of particular
+source formats.
+
+
+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, the way that you would for any project which is
+using 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.
+
+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.
+
+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.
+
+
+----------------------------------------
+
+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.
+
+But it's in your own interests, too:
+
+If you use dgit, you will be able to directly merge and/or cherry-pick
+NMUs, patches proposed via pull-request emails, and so on: Because, in
+this case, the dgit-using contributor will have based their work on
+your own history.
+
+Using dgit for your maintainer uploads will put your own history on
+browse.dgit.debian.org, rather than showing dgit's stub history (which
+can also be out of date).
+
+If you use dgit push, you get an extra check that the source package
+you are uploading is exactly the same as your git HEAD. This can
+save you some dsc-based checks.
+
+
+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.
+
+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'.)
+
+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.
+
+
+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
+ git merge -s ours dgit/sid
+before pushing. I'm intending to provide some rather more cookied
+way to do this but I have decided the exact shape yet.
+
+
+----------------------------------------
+
+There are a few other things I ought to cover, since they often come
+up:
+
+
+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.
+
+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 is
+choosing to use dgit, normally the maintainers's existing git history
+is more useful and interesting.
+
+
+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
+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.
+
+
+
+
+
+
+ cannot
+use such a git branch
+
+people have different contents in their git branches to in their
+
+
+
+To use dgit push, there are some things you may have to do
+differently.
+
+
+
+
+The point, of course, of using
+
+
+
+
+
+
+
+
+
+
+
+ defer talking about
+
+
~ijackson / talk-2015-debconf-dgit.git / commitdiff