Just a few instructions to get you started:

The above steps will create a repository with the appropriate layout for git-buildpackage, with three branches: master (where the Debian development will happen), pristine-tar, used by the pristine-tar tool during the package build process to recreate the original tarball, and upstream, which will contain the upstream source.

To display your name and more nicely in the Git log, you should instruct Git to do so (the --global option is to say Git these are the default parameters for every Git repository you commit to, without it the settings will be per-repository only):

After you create your debian/ (be sure to commit it!), you should add a “remote” to the repository. A remote is where the commits will be pushed to, and the default remote is called “origin”.

If you are going to push to our Alioth repository, please do the following inside your local repository:

The next step is to create the remote repository on Alioth.

This will create a packagename.git repository on Alioth, with the proper hooks set up for our team.

To push the package (make sure you've added the alioth remote!), do the following:

For the first push, it's necessary to specify “origin master”. The next time you will push, a git push will suffice. Remember that this will only push the “master” branch (and the other two only if master is somehow related to the new branches), so be sure to also do a run with --all, and one with --tags (if you obviously changed anything in the other branches/tags).

To build the package, just use the tools that svn-buildpackage carries. First of all, we suggest you to define some aliases for the most common commands:

Checkout the sources (see the proper section).

Once done, you're ready to do the work. First, cd to the trunk directory, and download the upstream sources (if there is a debian/watch file):

Alternatively, you can try this, it depends on how the package was built (again, from the trunk/ directory):

Once done, edit the files you need, and then build the package with svn-b or svn-br.

If you're a Debian Med member, you can commit your changes:

(also svn ci).

Otherwise, you can ask to be added to the group (see the Membership section), or send the result of svn diff to the mailing list (gzip -9 it, if it's too large).

You should use git-buildpackage to build the packages with git. Be sure to run it from the “master” branch.

Unfortunately, by default git-buildpackage builds the package without using any chroot (the same as svn-buildpackage), but it's configurable to run it inside a chroot.

You can use this configuration file, ~/.gbp.conf:

With this configuration file you're specifying that git-buildpackage will use ~/bin/git-pbuilder as the builder script. This is an example script you can use:

This will build the package inside the default cowbuilder chroot, while passing any more parameters directly do dpkg-buildpackage.

It may happen that a package version has been uploaded to Debian repositories, and you forgot to tag the last build with

You can tag this package also retroactively. A first step, creating the tags directory, can be achieved in two ways:

After the tags directory has been created, you're ready to tag the package:

(--svn-no-autodch avoids debian/changelog to be marked as UNRELEASED).

Tagging a release with git is pretty straightforward:

The tag names usually follow the scheme “debian/x.y-z”, this will ensure compatibility with other tools as well (like git import-dsc).

You can also easily retroactively make tags:

You're now at the point in history when you released the package. Just tag it as you would normally do.

After tagging, be sure to git push --tags, so that other people can benefit from it too.

To create a patch, use the new command. Run:

This will create (if it doesn't exist yet) a debian/patches/series file, which contains all the patches to be applied by quilt. Moreover, the new patch is also the topmost (the currently applied).

Now start editing files, with:

and repeat the process for each file the patch is involved with. At the end, run

This will compare the noted state of the edited files with the current state, and will produce a patch in debian/patches. Remember: the patch is currently applied (you can check this with quilt applied).

Just two easy commands to do the job:

You can just add a "-a" flag to the commands above, to respectively apply/unapply all patches in the series.

To edit a patch, first make it the topmost:

If the patch is already applied, but is not the topmost, run quilt pop until it becomes the currently applied one.

You can now run quilt edit on the files you want to change, and, when you're done, quilt refresh.

Sometimes it's useful to rename a patch. Without any hassle, do:

Please see man 1 quilt to have a comprehensive list of commands.

Add in the very first part of debian/rules (i.e. before the targets), the line:

Please use this to import patch and unpatch rules instead of writing them, and remember to add the needed dependencies to its targets:

This kind of dependency will ensure that if you also patch the build system, you get a working patched build process.

Now add a dependency to the clean target:

If you've also patched the build system, using upstream's clean target might fail. This is what you should do:

Obviously, you could always use an approach like this, but it's an useless complication if you don't patch the build system, and you should keep debian/rules the simplest you can.

dpatch-edit-patch

apply(-all), unapply(-all), status

dpatch-edit-patch

Is this possible?

Please see man 1 dpatch for a comprehensive list of commands.

Follow the instructions for quilt and adapt the path of inclusion to /usr/share/dpatch/dpatch.make