Introducing dgit - git integration with the Debian archive
I'm pleased to announce that dgit 0.7, which is a version of dgit
suitable for alpha and beta testers, is available in unstable.
>From the manpage:
dgit [dgit-opts] clone [dgit-opts] package [suite] [./dir|/dir]
dgit [dgit-opts] fetch|pull [dgit-opts] [suite]
dgit [dgit-opts] build|sbuild [build-opts]
dgit [dgit-opts] push [dgit-opts] [suite]
dgit treats the Debian archive as a version control system, and
bidirectionally gateways between the archive and git. The git
view of the package can contain the usual upstream git history,
and will be augmented by commits representing uploads done by
other developers not using dgit. This git history is stored in
a canonical location known as dgit-repos which lives outside
the Debian archive (currently, on Alioth).
If you don't like git, or think I have taken the wrong approach, then
you need read no further. You can carry on just as before.
If on the other hand you'd like to experiment with a new tool that
lets you work on any package in the archive using git, even with
upstream git history in your history if you like, and to share your
git-based work with other uploaders, please install dgit 0.7 from
unstable and try it out.
For more information, the full manpage is here:
(this is slightly more up to date than the one on manpages.debian.net).
This is still a very early version. I'm not aware of anyone but me
having used it in anger. So there are very likely to be bugs. Please
With regret I must note that currently you can't use it if you don't
have a full DD account on both the Debian systems and on Alioth. Even
if you just want a read-only mode. This is due to deficiencies in the
archive software and in Alioth, which I have worked around in very
unpleasant ways. I'm hoping that this will improve fairly soon.
Please see the BUGS section of the manpage.
The master git repository for dgit is here:
Pull requests welcome (please send them to the BTS).
At Debconf we had a series of discussion on the problem of integrating
git and the archive, culminating in an excellent bar-BOF. We started
with a diagram Joey Hess had drawn on a piece of cardboard, of a
design he had; many of us came to the BOF with our own preconceptions.
Too often these discussions result in a gigantic edifice which will
take six-months to implement and six years to persuade people is a
good idea. But, during this conversation, instead, pieces were hacked
off until the result was implementable right away. So that's what
Key points about dgit's design:
* It doesn't require anyone else to change their existing workflow.
* You can use it on any package.
* If you are the maintainer and want to use it on your own package,
it will allow you to adopt a gitish workflow and will let you
easily import into your git history the changes made in NMUs,
security updates - and hopefully eventually derivative distros.
* I think we can extend it later to support working on quilty
packages (with patch stacks) as if they were git branches. This is
not yet done because it's quite complicated. See PACKAGE SOURCE
FORMATS in the manpage.