GIT-DEBIMPORT(1)					      General Commands Manual						  GIT-DEBIMPORT(1)

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  pack-
	      ages 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 pos-
       sible  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 verba-
       tim 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)