GIT-UBUNTU-IMPORT(1)

📦 version 1.2, in ubuntu questing, ubuntu resolute, ubuntu stonking

🦋 git-ubuntu-import 💖

okay bestie, sit down, grab a strawberry 🍓, because this is the manual page for git-ubuntu-import and it is lowkey a lot, but we're getting through it together, no cap.

✨ NAME ✨

git-ubuntu-import — Import Launchpad publishing history to Git. that's it, that's the whole vibe. 💅

🌸 SYNOPSIS 🌸

git ubuntu import [-o | --lp-owner <owner>] [-l | --lp-user <user>]
[--dl-cache <dl_cache>] [--no-fetch] [--push] [--no-clean] [-d |
--directory <directory>] [--active-series-only] [--skip-applied]
[--skip-orig] [--reimport] [--allow-applied-failures] <package>

like, it's giving one command, one package, many flags. 🎀

👑 DESCRIPTION 👑

So here's the tea: this thing imports a source package's publication history from Launchpad into a local git(1) repository, and then pushes it to a remote repository. main character energy fr fr.

The importer algorithm roughly looks like this — and yes, we're keeping every single word, this is the lore:

Fetch the owner repository for <package>.

For <distribution> in "Debian", "Ubuntu":

    For each <publish> in <distribution> since the most recent
    patches-unapplied import in the local repository:

        Import the orig tarballs for <publish> using "gbp import-
        orig --pristine-tar", unless they have already been imported
        and the imported tarballs are identical.

        Find a <changelog parent>: the most recent changelog entry
        with a corresponding patches-unapplied import.

        Find an <upload parent>: an upload-tag in the repository for
        the same version as <publish> with git-tree-identical
        contents as <publish>.

        Commit the git tree corresponding to a patches-unapplied
        extraction of <publish> using <changelog parent> and <upload
        parent> as parents.

        If this is the first patches-unapplied import of a given
        version, create a tag in refs/tags/import/ pointing to the
        new commit.

        Update the patches-applied <distribution>/<publish's
        series>/<publish's pocket> branch to the new commit.

For <distribution> in "Debian", "Ubuntu":

For each <publish> in <distribution> since the most recent patches-
applied import in the local repository:

    Find a <changelog parent>: the most recent changelog entry with
    a corresponding patches-applied import.

    Find an <unapplied parent>: the corresponding patches-unapplied
    import of <publish>'s version.

    Commit each git tree corresponding to the application of the
    next quilt patch in <publish> using <changelog parent> and
    <unapplied parent> as parents.  As each quilt patch is applied,
    the <unapplied parent> becomes the result of the immediately
    prior patch's application.

    If this is the first patches-applied import of a given version,
    create a tag in refs/tags/applied/ pointing to the commit
    corresponding to the application of the final quilt patch.

    Update the patches-applied <distribution>/<publish>'s
    series/<publish>'s pocket branch to the new commit.

see? two whole passes: first the patches-unapplied era, then the patches-applied era. it's a whole saga. 😭

💅 OPTIONS 💅

-o <owner>, --lp-owner <owner> — the Launchpad owner of the remote repository. we fetch the current repository from them and push the resulting import to them. 👑
-l <user>, --lp-user <user> — the Launchpad user to authenticate as, for push URLs and also for the default personal remote we create. if you don't pass it, the value comes from git config --global gitubuntu.lpuser. and if that config value isn't set either? it literally prompts you for it. 🫶
--dl-cache <dl_cache> — the path to use for caching downloads from Launchpad. by default, downloads get cached inside the repository's GIT_DIR. ✨
--no-fetch — do not fetch the <owner>'s repository before importing. we're skipping the fetch, respectfully. 🙈
--push — confirm that you want to push the resulting import to the <<owner>'s repository after importing. this is not the default, because for local purposes — operating outside the importer service — this is not usually wanted. 🚨
--no-clean — do not delete the local directory used for the import upon completion. leave the mess, we love her. 🎀
-d <directory>, --directory <directory> — the local directory to perform the import in. this implies --no-clean. if you don't specify one, a temporary directory gets used instead. 🦋
--active-series-only — instead of importing all publications from Launchpad, only consider the ones for the currently active series. this can be useful to just get a quick view of the current state in the archive, because a full import can take a very long time. ⏳
--skip-applied — only perform the patches-unapplied portion of the algorithm in DESCRIPTION. this can be useful to just get a quick view of the current state in the archive, because a full import can take a very long time. 🌸
--skip-orig — do not attempt to import the orig tarballs. this can be useful to just get a quick view of the current state in the archive, because a full import can take a very long time. this option can also be useful for git-ubuntu(1) developers when debugging issues with gbp or pristine-tar. 🧚
--reimport — reimport the given source package from scratch. the reimport will still incorporate upload tags as currently present in the remote repository. this option is only intended for git-ubuntu(1) developers, and it's used when the SHA1s of commits must change due to an implementation change in git ubuntu-import. a typical reimport of a repository (for safety) looks like this:

git ubuntu import --reimport --no-clean <package>

This will leave a local directory with the resulting reimport. The local directory should be examined for the reimport's success; in particular, that upload tags are reincorporated in the new history.

git ubuntu import --reimport --no-fetch --directory <tempdir from prior command>

This will use the local directory, which is current as of the prior reimport, ensure it is still current (in case new publishes have occurred) and forcibly git-push the resulting repository to <owner>'s remote repository. 🔥

--allow-applied-failures — do not treat a patch application as a hard failure when importing the patches-applied history. because dpkg-source(1)'s (or other tool's) behavior has evolved over time, it's possible that the version used by git ubuntu import is not able to reproduce the patch application of a historical publication. by default, such a failure will stop the historical import for the patches-applied branch, to allow a git ubuntu developer to investigate. after investigation, this flag can be used to indicate the importer is allowed to ignore such a failure. 💀
<package> — the name of the source package to import. the one and only. ⭐

real talk: --reimport and --allow-applied-failures are developer territory. if you're not debugging the importer itself, these are not your girls. 🙅

🫶 EXIT STATUS 🫶

git ubuntu import exits with status 0 if the import completes successfully. it exits with nonzero exit status on errors. that's the vibe check. ✅❌

😭 REPORTING BUGS 😭

Report bugs at https://bugs.launchpad.net/git-ubuntu — please and thank you, the devs deserve to know. 💜

🌈 SEE ALSO 🌈

quilt(1)

⭐ GIT-UBUNTU ⭐

Part of the git-ubuntu(1) suite. the whole fam. 👑

okay that's the whole page, you ate that. 💖 this was Git-Ubuntu 0.2, dated 2017-07-19 — so yeah she's vintage, but she's still iconic. mwah, go import something. 🎀✨🦋

📦 where this page comes from

ubuntu questing: git-ubuntu 1.1-2
ubuntu resolute: git-ubuntu 1.1-2build1 · GPL-3.0-only
ubuntu stonking: git-ubuntu 1.2-3 · GPL-3.0-only
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-10-13: a language model's rewrite of the original, under its terms