Debian's Git Transition

Debian’s git transition Dec . 21st , 2025 11:24 pm diziet tl;dr: There is a Debian git transition plan. It’s going OK so far but we need help, especially with outreach and updating Debian’s documentation. Distributing the source code as git Roadmap Mindshare and adoption - please help! Personnel Goals of the Debian git transition project Everyone who interacts with Debian source code should be able to do so entirely in git. That means, more specifically: All examination and edits to the source should be performed via normal git operations. Source code should be transferred and exchanged as git data, not tarballs. git should be the canonical form everywhere. Upstream git histories should be re-published, traceably, as part of formal git releases published by Debian. No-one should have to learn about Debian Source Packages, which are bizarre, and have been obsoleted by modern version control. This is very ambitious, but we have come a long way! Achievements so far, and current status We have come a very long way. But, there is still much to do - especially, the git transition team needs your help with adoption, developer outreach, and developer documentation overhaul. We’ve made big strides towards goals 1 and 4. Goal 2 is partially achieved: we currently have dual running. Goal 3 is within our reach but depends on widespread adoption of tag2upload (and/or dgit push). Downstreams and users can obtain the source code of any Debian package in git form. ( dgit clone , 2013). They can then work with this source code completely in git, including building binaries, merging new versions, even automatically (eg Raspbian , 2016), and all without having to deal with source packages at all (eg Wikimedia 2025). A Debian maintainer can maintain their own package entirely in git. They can obtain upstream source code from git, and do their packaging work in git ( git-buildpackage , 2006). Every Debian maintainer can (and should!) release their package from git reliably and in a standard form ( dgit push , 2013; tag2upload , 2025). This is not only more principled, but also more convenient, and with better UX, than pre-dgit tooling like dput . Indeed a Debian maintainer can now often release their changes to Debian, from git, using only git branches (so no tarballs). Releasing to Debian can be simply pushing a signed tag ( tag2upload , 2025). A Debian maintainer can maintain a stack of changes to upstream source code in git ( gbp pq 2009). They can even maintain such a delta series as a rebasing git branch, directly buildable, and use normal git rebase style operations to edit their changes, ( git-dpm , 2010; git-debrebase , 2018) An authorised Debian developer can do a modest update to any package in Debian, even one maintained by someone else, working entirely in git in a standard and convenient way (dgit, 2013). Debian contributors can share their work-in-progress on git forges and collaborate using merge requests, git based code review, and so on....

Preview: ~500 words