Sean Whitton: dgit-as-a-service retrospective

We recently launched tag2upload, aka cloud dgit or dgit-as-a-service.
This was something of a culmination of work I’ve been doing since 2016 towards
modernising Debian workflows, so I thought I’d write a short personal
retrospective.

When I started contributing to Debian in 2015, I was not impressed with how
packages were represented in Git by most package maintainers, and wanted a
pure Git workflow. I read a couple of Joey Hess’s blog posts on the matter,
a rope ladder to the dgit treehouse and upstream git repositories
and made a bug report against dgit hoping to tie some things together.

The results of that early work were the git-deborig(1) program and the
dgit-maint-merge(7) tutorial manpage. Starting with Joey’s workflow
pointers, I developed a complete, pure Git workflow that I thought would be
suitable for all package maintainers in Debian. It was certainly well-suited
for my own packages. It took me a while to learn that there are packages for
which this workflow is too simple. We now also have the
dgit-maint-debrebase(7) workflow which uses git-debrebase, something
which wasn’t invented until several years later. Where dgit-maint-merge(7)
won’t do, you can use dgit-maint-debrebase(7), and still be doing pretty much
pure Git. Here’s a full, recent guide to modernisation.

The next most significant contribution of my own was the push-source
subcommand for dgit. dgit push required a preexisting .changes file
produced from the working tree. I wanted to make dgit push-source prepare
that .changes file for you, but also not use the working tree, instead
consulting HEAD. The idea was that you were doing a git push – which
doesn’t care about the working tree – direct to the Debian archive, or as
close as we could get. I implemented that at DebConf18 in Taiwan, I think,
with Ian, and we also did a talk on git-debrebase. We ended up having to
change it to look at the working tree in addition to HEAD to make it work as
well as possible, but I think that the idea of a command which was like doing
a Git push direct to the archive was perhaps foundational for us later wanting
to develop tag2upload. Indeed, while tag2upload’s client-side tool
git-debpush does look at the working tree, it doesn’t do so in a way that is
essential to its operation. tag2upload is dgit push-source-as-a-service.

And finally we come to tag2upload, a system Ian and I designed in 2019 during
a two-person sprint at his place in Cambridge, while I was visiting the UK
from Arizona. With tag2upload, appropriately authorised Debian package
maintainers can upload to Debian with only pure Git operations – namely,
making and pushing a signed Git tag to Debian’s GitLab instance. Although we
had a solid prototype in 2019, we only finally launched it last month,
February 2026. This was mostly due to political delays, but also
because we have put in a lot of hours making it better in various ways.

Looking back, one thing that seems notable to me is that the core elements of
the pure Git workflows haven’t changed much at all. Working out all the
details of dgit-maint-merge(7), designing and writing git-debrebase (Ian’s
work), and then working out all the details of dgit-maint-debrebase(7), are
the important parts, to me. The rest is mostly just large amounts of
compatibility code. git-debrebase and dgit-maint-debrebase(7) are very novel
but dgit-maint-merge(7) is mostly just an extrapolation of Joey’s thoughts
from 13 years ago. And yet, adoption of these workflows remains low.

People prefer to use what they are used to using, even if the workflows have
significant inconveniences. That’s completely understandable; I’m really
interested in good workflows, but most other contributors care less about it.
But you would expect enough newcomers to have arrived in 13 years that the new
workflows would have a higher uptake. That is, packages maintained by
contributors that got involved after these workflows became available would be
maintained using newer workflows, at least. But the inertia seems to be too
strong even for that. Instead, new contributors used to working purely out of
Git are told they need to learn Debian’s strange ways of representing things,
tarballs and all. It doesn’t have to be that way. We hope that tag2upload
will make the pure Git workflows seem more appealing to people.