+The other implementation would have the pushed branch stashed away
+somewhere and "revealed" only when it was ready, if it was still a
+fast forward. That makes it tricker for someone else to find it to
+work on top of it, and is more work to implement, but it's probably
+better.
+
+
+It would be easy for dgit, when pushing an NMU, to construct the
+NMUdiff and email it to the BTS. Of course a maintainer can fetch
+your NMU as git commits easily with dgit fetch, but maybe the
+maintainer isn't using dgit (or, even, isn't using git at all), so you
+for the benefit of those maintainers we should still be sending these
+diffs.
+
+
+dgit push is slightly more work than it needs to be when doing a
+source-only upload. In this case there is not really any need for a
+separate `dgit build-source' step. I think there should be a way to
+have dgit push make the source package as well, since it easily can.
+
+
+The dgit git server has most of the moving parts to become a
+fairly-general-purpose git server with access control equivalent to
+the Debian archive. In this role it could replace some uses of
+Alioth, which is good because Alioth is doing too many other things.
+
+In particular, with the use of signed pushes, we could have
+traceability of pushes, which makes a gitish packaging workflow more
+practical - in particular, maintainers would not need to as thoroughly
+audit work found on for-upload branches on the git server, before
+pushing the code to the archive. (I suspect many maintainers already
+don't do this as thoroughly as they should.)
+
+
+dgit requires the suite branches to be fast forwarding. If you have a
+workflow involving git rebase, you need to make a fake merge (ie, a
+merge made with git merge -s ours), at the tip of your branch, to make
+it be a fast forward from the previous state of the suite branch. And
+then when you want to work on the package again, you need to strip
+that same fake merge.
+
+This can be done with raw git operations (git merge and git reset)
+quite easily, but it's ugly. Also doing it by hand like this doesn't
+provide many safety catches.
+
+I intend to provide some tooling which will help with this, but I
+haven't exactly decided what the UI should be and how it should work.
+
+
+The final thing I can do myself is arrange for non-dgit uploads to be
+automatically converted, and appended to the dgit suite branches on
+the dgit git server. That would make the dgit history, as shown on
+browse.dgit.debian.org for example, for any package be more useful,
+starting with the first dgit-based upload. In particular it would
+avoid the browse view ever being out of date.
+
+
+There are also some things that I need help with.
+
+The documentation for how dgit works together with existing git
+management tools is rather sparse.
+
+Ideally each git workflow tool would explain how (or whether) it works
+with dgit. Tasks that should be covered include how to incorporate
+changes made in an NMU into the tool's favoured history format, and
+how to upgrade a package to a new upstream version. I have spoken to
+the git-buildpackage and git-dpm maintainers about this. I'm
+optimistic particularly about git-buildpackage.
+
+
+There is a difficulty with empty directories in source packages. git
+refuses to handle empty directories - they tend to just vanish from
+commits and checkouts. But I'm told there are some source packages
+whose orig tarballs contain empty directories, and build systems
+depend on those empty directories.
+
+Currently if you dgit clone such a package, it won't build. I don't
+have a particularly good answer to this problem right now. It's no
+good to have dgit create these directories in the working tree, when
+it notices, because the git branches might be transported by plain git
+and used elsewhere.
+
+This can be worked around in the source package by either adding
+something to debian/rules to create these directories, or by adding
+some files to the directories to make them nonempty. But at the
+moment a maintainer is not required to do either of these things.
+
+
+And then there are a couple of exciting possibilities for new uses:
+
+Firstly, it would be very nice to have a way for a sponsee to provide
+a dgitish git branch, which the sponsor could work with directly and
+ultimately dgit push. I'm really need to talk about this with some
+people more familiar than me with the sponsorship queue
+infrastructure.
+
+
+
+Secondly, dgit is not just for Debian. Other distros currently using
+only source packages can use it too. Read-only support doesn't
+necessarily depend on specific support at the distro end. So, you can
+already dgit fetch from ubuntu; I'd welcome patches for read-only
+support for Mint, for example.
+
+dgit push support requires a suitably set up git server, and maybe
+some thought, depending on the distro's views on push access control.
+I hear rumours that Ubuntu might grow a dgit git server and support
+dgit push. Patches very welcome!
+
+
+==== Thanks and more info slide
+
+Finally, there are some people I need to thank.
+
+At least half of the design of dgit is Joey Hess's, at the now-famous
+session in Vaumarcus.
+
+Debian System Administration, and particularly Peter Palfrader, have
+been absolutely brilliant. The level of service and competence has
+been outstanding. Ever time I noticed some aspect I had forgotten,
+and made a blatherous and ill-thought-out request, DSA would propose a
+much better alternative and implement their end of it it almost
+immediately.