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>.

                                               September 21, 2007                               GIT-DEBIMPORT(1)