NAME¶
git-debimport - create a git repository from a set of existing Debian packages
SYNOPSIS¶
git-debimport [
options]
path-prefix
DESCRIPTION¶
This program will create a git repository of all files that match
${path-prefix}_*.diff.gz or ${path-prefix}_*.debian.tar.{gz,bz2,xz} (with
their corresponding orig.tar.{gz,bz2,xz}), or of all files that match
${path-prefix}_*.tar.{gz,bz2,xz} (for Debian native packages).
OPTIONS¶
The following options are available:
- --fetch
- Attempt to download all available versions from snapshot.debian.org rather
than use an existing set of packages. The debsnap(1) utility, from
devscripts 2.10.63 or later, must be available in the path to use this
option (earlier debsnap versions only supported snapshot.debian.net
which is no longer a functional mirror). The packages will be downloaded
into the location implied by the path-prefix where they would
normally be expected to exist already without this option. Downloaded
packages will not automatically be removed after this operation is
complete.
- --late-merge
- Early versions of git-debimport would only merge the upstream and
debian branches after the import of all packages was complete. This avoids
an import failing where the merge might have conflicts that would need to
be manually resolved. We know the import of the next package in the series
will contain a resolution to any such conflict, so delaying the merge
allows the import to proceed without intervention or introducing changes
that were not part of the original history. It does however produce a
lesser quality history for the purposes of browsing the Debian changes.
All the original packages may be retrieved from such a repo with perfect
fidelity, but the diff between adjacent Debian versions will be mingled
with upstream changes too.
The default for current versions of git-debimport is to merge each
new upstream release as it is imported. This gives a much more natural and
useful looking history, but may fail in some cases. Use this option to
employ the older more reliable method for packages that generate conflicts
during import.
- -v, --verbose
- Be more noisy about reporting operations in progress. Mostly only useful
with the --fetch option at present.
EXAMPLE¶
Import an archive of existing 'mypackagename' packages from mysrcdir:
$ mkdir mydestdir && cd mydestdir
$ git-debimport ../mysrcdir/mypackagename
Import all available versions of
gitpkg from snapshot.debian.org:
$ mkdir mydestdir && cd mydestdir
$ git-debimport --fetch ../my-gitpkg-sources/gitpkg
NOTES¶
It is unfortunate that at the present time, many of the tools for importing
source to git from an existing revision control system all leave something to
be desired. This script does not solve that problem. What it does do however
is create a repository that makes it possible to accurately extract all of the
earlier packages which were injected to it. This is sadly more than can be
said for the result of running git-cvsimport on a repo created by
cvs-buildpackage, for example.
It is currently very simple, and makes a number of hard-coded assumptions about
the resulting repo. For debian-versioned packages it will create a repo with
two branches:
upstream - for the pristine upstream source
master - for the Debianised source
Native versioned packages will have only the master branch.
While the loss of fine grained history on individual commits is most
regrettable, this script enables a maintainer to import a usable record of the
previously released packages as a base for future development. This may be an
acceptable trade-off for people who feel the advantage of moving future
development to git now outweighs the inconvenience of needing to refer to a
legacy repository for full details of previous commits.
Hopefully the problems of accurately importing from other revision control
systems will be solved one day, but in the meantime, a brief but accurate
history seems more useful than a detailed but largely bogus one.
With the addition of the
debsnap(1) tool, the useful life of this has
been extended beyond the originally envisaged need. People who do not have
access to the original revision control history at all can build for
themselves a useful base for further development, quickly and easily, from the
packages that are still available on public snapshot mirrors.
BUGS¶
git-debimport does not currently handle packages with mixed 'native' and
debian-versioned releases. This may be added in a later version if people have
real examples of such packages they wish to import with it and we figure out a
sensible convention for how they should be stored in the resulting repository.
Nothing particularly intelligent is done with format 3.0 (quilt) patches
currently. The debian/patches, if any, are simply imported verbatim as found
in the source package. Ideally they should be committed to some git branch and
generated on demand at export time, rather than perpetuating the
patch-in-patch nightmare. Any packages so imported will be recreated
accurately on export, but this isn't really the best form to actually work
with them in git in most cases.
SEE ALSO¶
gitpkg(1),
debsnap(1)
AUTHOR¶
gitpkg was written by Ron <ron@debian.org>.