Installation

The dgit push command triggers two processes: First, the command signs the newly built source package with the maintainer's GPG key and uploads it to the Debian archive. This is exactly what the Debsign (package: devscripts) and Dput (package: dput-ng) tools do separately. The upload is an anonymous FTP upload to the ftp.upload.debian.org server.

Second, the command tags your current code snippets with the debian/<packageversion> [6] standard format and synchronizes the dgit repository on the Debian Alioth server with your own working directory. The Git history of the packages processed with dgit will not end up in the Debian archive. Instead, anyone interested in examining individual changes can browse the logged commits online later [7].

If a user clones a package that has been processed with dgit previously or updates an existing local repository using dgit fetch, dgit restores the Git history stored on the dgit server. To keep the source package and Git repository in sync at all times, there is now a special dgit field for the control files (.dsc) in the Debian archive, which contains the hash of the corresponding Git commits [8].

If you run dgit push without upload privileges, the connection to the Debian archive and the dgit server breaks down. In this case, dgit converts the current commits to patches. Users can then send these packages to the developers or provide them on a bug-tracking system. You will face no restrictions to cloning.

Progress

Of course, dgit is primarily useful to Debian developers, offering an approach to manipulating packages on the fly or recurrently – even outside of the developer groups – in Git. Dgit also offers a development interface for occasional work on packages that are not maintained or do not have a fixed maintainer. The good thing is that the software does not discard the commit history but stores it in a central place, making it visible online. After all, some users will have a good reason to track the progress that a package is making.

Dgit is very well suited to package sponsoring, which is where experienced Debian developers check the work by newcomers before uploading. Dgit is also useful for admins who maintain local versions of official Debian packages with special customizations for certain systems. Until now, developers have had to repeatedly copy the local patch into a new source directory whenever the archive was updated, in order to build updated binary packages. With dgit, the maintainer simply merges the new versions of the source package into the working directory and integrates the changes, thus keeping the local modifications. Finally, dgit also benefits downstream developers – for example, maintainers of Debian derivatives. The integration options grow if you provide Git repositories from the Debian archive instead of an FTP mirror.

Conclusions

Compared with legacy procedures for handling Debian source packages and the Debian archive, dgit offers many benefits and modernizes access to the Debian archive.

It remains to be seen whether dgit will find widespread acceptance among Debian developers and whether a significant number of packages will start appearing on the dgit server. Dgit may be open for integration into existing Git workflows of the Debian developer groups; however, the overhead necessary to support this integration might exceed the value it adds.

Nonetheless, dgit is a useful and potentially future-oriented feature for the package archive, and this makes me optimistic that it will – in the long-term – attract the interest of Debian developers. Dgit's strengths are apparent even without a focus on collaborative aspects. The Git access that is available through dgit gives you the option for tapping into an archive for read-only access. Ubuntu is now using dgit as a tool for supporting read-only access [9].

Other sophisticated options, such as the ability to exchange changes made to edited packages, puts dgit, with its separate workflow, on a par with alternative tools like git-buildpackage and git-dpm [10].