Translator(s): English - Indonesian

Maintaining Debian source packages in git with git-dpm

This page describes how to use git-dpm. For instructions how to use the git-buildpackage family of commands, look at PackagingWithGit.

design goals

The main design goals are:

Make the generated source packages dsc format 3.0 (quilt).
- So users unpacking the source packages from their CD or one of the Debian mirrors
  can easily evaluate the modifications and also look at them at patch-tracker. When they unpack a package with dpkg-source they get the final source (no understanding of any patch system needed).
Store the patches as permanent git commits.
- Patches are imported at most once and then live as git commits and are edited with git methods (amend, rebase, ...). No repeated translation from patch to commit back to patch back to commit. Upstream or people from other distributions can just cherry-pick patches from your repository.
Contain all information in one branch that can pushed and pulled fast-forwardly.
- While git rebase -i is the better quilt, git has no easy way to collaborate on such a branch or to retain its history. That's why in a git-dpm based workflow the patched branch is not published as git branch but only as a merged part of the history.
Look as similar as results from Debian tools as possible
- The result of an git clone should be similar enough to the source package unpacked with dpkg-source -x, so one can point users not familar with git or git-dpm to the version stored in git to be able to test unfinished versions. Allow removal of files in the debian branch relatively to the upstream branch to support the traditional way of removing files modified by the build process in debian/rules clean.

documentation

As with most tool, documentation can always be improved. I hope this page will also get some more examples and explanations added.

How to start

You can either import .dsc files or start from scratch.

Common operations

Build a package

git-dpm prepare && dpkg-buildpackage -rfakeroot -us -uc

will check everything is ready (possibly checking out a missing .orig.tar file using pristine tar) and then build it. (Usually it should suffice to just place the .orig.tar file in the parent directory and call dpkg-buildpackage, but git-dpm prepare will make sure you are not in the middle of some change and the correct .orig.tar file is there).

Add a patch

To write a patch yourself:

git-dpm checkout-patched
vim files
git commit -a
git-dpm update-patches

Include a patch file

git-dpm apply-patch patchfile
git-dpm update-patches

Cherry pick a commit from upstream:

git-dpm cherry-pick commit
git-dpm update-patches

(You of course only need the update-patches command once you are done and not if you want to add more stuff or edit any of the patches afterwards).

Tricks

users of git-buildpackage are used to see the new upstream committed to pristine-tar; this can be achieved by changing a configuration default of git-dpm like this:

git config --global dpm.pristineTarCommit true

users of git-buildpackage are also used to see branches tagged for each version ; that can be achieved by adding the following to debian/.git-dpm (hence it's a per-package setting) :

debianTag="debian/%e%v"
patchedTag="patched/%e%v"
upstreamTag="upstream/%e%u"

other stuff

to be continued ...

shortcomings

As git-dpm is quite new, it usually misses many of the nice gimmicks and some of the automatisms the tools from the git-buildpackage family offer.
multiple upstream tarballs are implemented but could need some testing...
documentation is horrible (your humble author is bad at writing documentation even beyond the usual non-native speaker's inability to do so)

PackagingWithGitGitDpm