+If you're not in the habit of forgetting to say git-add, you can set a
+configuration option to have dgit always use git-clean. Then you will
+never have to fight a buggy clean target, in a strange package, ever
+again.
+
+
+
+==== Future plans slide
+
+I have a number of plans for the future, some of which I may even get
+around to:
+
+
+dgit can't currently upload to DELAYED queues, which makes it a bit
+awkward for a fire-and-forget NMU. One way to implement this would be
+to push to the suite branch but send the package upload to DELAYED.
+But such an upload which was deleted by the maintainer would still
+present be in the suite branch, and the changes might be resurrected
+by a future dgit user. At the very least there should be a way for
+the maintainer to revert a push which was accompanied by a DELAYED
+upload.
+
+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.