Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2010-08-08 10:41:45
Size: 1718
Editor: ?BernhardRLink
Comment: Begin description of git-dpm.
Revision 3 as of 2010-08-08 11:00:48
Size: 2600
Editor: ?BernhardRLink
Comment: add some disadvantages
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
 * 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.
Line 36: Line 41:
       == 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 not yet supported (but should be no big problem to add).
 * documentation is horrible (your humble author is bad at writing documentation even beyond the usual non-native speaker's inability to do so)

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. Currently there is some on the git-dpm website. I hope this page will also get some more examples and explanations added.

How to start

TBW

Common operations

TBW

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 not yet supported (but should be no big problem to add).
  • documentation is horrible (your humble author is bad at writing documentation even beyond the usual non-native speaker's inability to do so)