Git Happy

Version management systems are a fundamental building block of professional software development. Many projects use Git [1], a version control tool created by Linux founder Linus Torvalds for the Linux kernel developer community. Git offers a distributed development environment with many benefits, such as revision management and flexibility with exchanging code, but it is difficult for a development project with large, legacy archives to interface with the Git environment. A helpful tool known as dgit brings the power of Git to the entire Debian archive. See Table 1.

Dgit which was created by Ian Jackson, treats the whole Debian archive as a version control system and serves as a "bidirectional gateway between the archive and Git." Dgit [2] lets users load arbitrary source packages from the archive into a local Git repository, then work on them with Git techniques, and finally build the binaries (Figure 1). Package maintainers can use dgit to feed their changes back into the Debian archive.

Figure 1: The dgit repository. The current version is 1.4.

Clones

Developers install dgit as a CLI tool. The dgit clone <packagename> command (Figure 2) retrieves any source package from the Debian archive [3]. This step is equivalent to calling apt-get source <packagename>, although you do not need to state a deb-src package source in the /etc/apt/sources.list file. After downloading with dgit, you'll be missing the registry file (.dsc) and the tarball with the Debian files (.debian.tar.xz), but there is no need to unpack the source package using dpkg-source -x.

Figure 2: You can use a clone command to retrieve any number of source packages from the Debian archive.

The source directory is now controlled by Git; you can check this by going to the source directory and by typing git status. To see whether someone has already managed the package with dgit, you can run the git log command. If not, you will see a comment telling you that the package was imported from the archive.

If you do not specify a Debian branch (using dgit <packagename> <branch>), Debian retrieves the source package from the Unstable developer version. You can verify this branch name by reference to the name of the current Git branch by typing git branch; in the example, the response will be dgit/sid.

Package Maintenance

Administrators maintain packages by writing patches for changes to the upstream code or modifying the control files in debian/. Dgit offers you all the Git options for your work on the source directory, thus providing an uncomplicated way of trying things out and reworking changes that you stored, or letting you simply discard the changes. If desired, you can use experimental Git branches for your development.

Debian maintainers can use Debian package maintenance tools in a Git repository (Figure 3). For example, Debcommit (package: devscripts) automatically generates commit messages from entries in debian/changelog.

Figure 3: Gitk lets you process Debian packages.

Some developer groups have been maintaining their packages in public Git repositories for a long time. The matching URL is stored in the Vcs-Git field of the debian/control file. Dgit automatically sets up the group repository as an additional remote repository after cloning; this leads to a Remote: vcs-git entry in the .git/config file.

For a three-way exchange of code, users could include the upstream repository to the Git remotes. It's easy to use this source for cherry-picking from the latest code in a local copy of the upstream repository in Debian patches.

Building

If you want to upload a new package version to the archive or generate binary packages (.deb), you can build from within the Git directory. Dgit offers wrappers for various build tools, such as the chroot builder Sbuild [4]. If a chroot [5] of Unstable already exists, dgit builds the new source package along with the binary packages with the dgit sbuild command, optionally in a RAM overly. However, you need to specify the dgit cleaning option, -wdd, to work around the availability check before changes to the chroot environment.

Another useful default setting in dgit is automatically applying the mergechanges scripts after the build (package: devscripts). This setting references the _<arch>.changes file to create another _multi.changes file that is suitable for source-only uploads. Dgit prefers this approach when uploading; the Build network then rebuilds the binary package for the architecture used locally – which is the generally recommended approach. For this strategy to work properly, you need to specify the --mergechanges:-i dgit option or configure the tool with this option.