GIT-DEBIMPORT(1)

💖 NAME 💖

git-debimport — bestie, this makes a whole git repo out of a pile of Debian packages you already have lying around. slay.

---

✨ SYNOPSIS ✨

git-debimport [options] path-prefix

---

🦋 DESCRIPTION 🦋

okay so here's the vibe: this program builds you a git repository out of all the files that match ${path-prefix}_*.diff.gz or ${path-prefix}_*.debian.tar.{gz,bz2,xz} — and it brings their corresponding orig.tar.{gz,bz2,xz} along for the ride 💅 — or, if you're dealing with Debian native packages, out of all the files that match ${path-prefix}_*.tar.{gz,bz2,xz}.

that's it. that's the whole job. iconic.

---

🎀 OPTIONS 🎀

here's everything you can pass it, no gatekeeping:

• --fetch — instead of using the packages you already have, it goes and downloads every available version from snapshot.debian.org. to do this you need the debsnap(1) utility, from devscripts 2.10.63 or later, chilling in your path (older debsnap versions only ever supported snapshot.debian.net, which is not a functional mirror anymore, so like… don't). the packages land in the location implied by path-prefix — the exact spot they'd normally be expected to already exist in if you hadn't used this option. and heads up: downloaded packages are not automatically removed once the operation finishes. they stay. they live there now 🫶
• --late-merge — storytime: early versions of git-debimport would only merge the upstream and debian branches after the import of all packages was complete. why? because it dodges the import failing when the merge might have conflicts that someone would have to resolve by hand. the logic is that the import of the next package in the series will contain a resolution to any such conflict, so delaying the merge lets the import proceed without intervention and without introducing changes that weren't part of the original history. the catch? it produces a lesser quality history for browsing the Debian changes 😭. all the original packages can still be retrieved from such a repo with perfect fidelity, but the diff between adjacent Debian versions gets mingled with upstream changes too.

the default for current versions of git-debimport is to merge each new upstream release as it's imported. this gives a much more natural and useful looking history, but it may fail in some cases. so use this option to employ the older, more reliable method for packages that generate conflicts during import. pick your fighter 💀

• -v, --verbose — be more noisy about reporting operations in progress. mostly only useful with the --fetch option at present. like it's giving commentary track energy but only during fetch rn.

---

🌈 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 👑

ngl, it's unfortunate that right now, a lot 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 is create a repository that makes it possible to accurately extract all of the earlier packages that were injected into it. and sadly, that's more than can be said for the result of running git-cvsimport on a repo created by cvs-buildpackage, for example. 💀

it's currently very simple, and it 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. fr fr. ✨

and with the addition of the debsnap(1) tool, the useful life of this has been extended beyond the originally envisaged need. people who don't 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. that's the dream, honestly 🌸

---

🙈 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. so like… send examples? maybe? 👀

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. it's giving chaos but make it reproducible 😭

---

⭐ SEE ALSO ⭐

gitpkg(1), debsnap(1)

---

💜 AUTHOR 💜

gitpkg was written by Ron <ron@debian.org>.

---

okay bestie that's the whole page, you're officially educated 💅 this was the git-debimport page from the General Commands Manual, dated September 21, 2007 — go forth and import, mwah 🎀✨