gitpkg (0.31+nmu1build1) resolute; urgency=medium

  * No-change mass rebuild for Ubuntu 26.04 (LP: #2132257)

 -- Graham Inggs <ginggs@ubuntu.com>  Tue, 20 Jan 2026 20:40:58 +0000

gitpkg (0.31+nmu1) unstable; urgency=medium

  * Non-maintainer upload.
  * Convert to source format 3.0.  Closes: #1007394
  * d/copyright: Convert to machine-readable format.

 -- Bastian Germann <bage@debian.org>  Wed, 17 Apr 2024 20:57:23 +0000

gitpkg (0.31) unstable; urgency=medium

  * Support exporting submodules as part of the superproject package.
    Closes: #734360
    It's been a while since we had any follow up or feedback on the discussion
    in that bug, so it's not clear that submodules remain a wide use case, but
    I've now got one upstream repo really using them (though it probably would
    be better organised differently too) so I at least have something concrete
    to base the gitpkg behaviour on rather than just a strawman speculation on
    my part about how a repo with submodules might be arranged and operated.

    The originally proposed patch had quite a few limitations, it only worked
    on exports of the debian-treeish, not for a real orig-branch, and it used
    git submodule foreach, which only works on the current checked out state
    of the working dir and so breaks one of gitpkg's fundamental modes of
    operation where any revision can be exported at any time, regardless of
    the current state of the repo working dir.  This implementation is quite a
    bit more involved, but it should handle most or all cases, including where
    submodules have been moved or later deleted, provided the local repo has
    been fully initialised and all submodules which may need to be exported
    have been cloned into the superproject and its full history is intact.

    It will not simply export submodules by default, though it if finds them
    present in a repo that has not been configured to export (or ignore) them
    then it will prompt asking what immediate action should be taken and
    suggest configuration to avoid be prompted again subsequently.  This way
    existing repos that have been silently ignoring submodules thus far will
    not silently do something surprisingly different with this gitpkg release.

  * Sanity check and/or warn if gitpkg is invoked from a submodule dir, since
    that probably won't do what a lot of people might naively assume, but it
    might still be something that some pathological repo actually has a use
    case for.  We probably shouldn't encourage it though.

  * Bump to debhelper compat 12.  That give us no-patch builds back to buster
    which is still a supported release.  We don't actually need anything from
    newer dh in this package, so this is just to stay ahead of the arbitrary
    'deprecated version' warnings rather than to actually fix anything.

 -- Ron Lee <ron@debian.org>  Sat, 30 Sep 2023 18:12:57 +0930

gitpkg (0.30) unstable; urgency=medium

  * New utility functions in repo-config-helper which simplify configuration
    option handling in hook scripts.
  * Provide finer grained overrides for usefully configurable options in the
    cowpoke and dpkg-buildpackage exit hooks, so that overriding things like
    the target to build for, or where to upload, don't necessarily override
    all of the other configured defaults.
  * Support creating "source only" changes files for upload, even when doing
    a full binary package build.

 -- Ron Lee <ron@debian.org>  Tue, 10 Aug 2021 01:00:34 +0930

gitpkg (0.29+nmu1) unstable; urgency=medium

  * Non maintainer upload by the Reproducible Builds team.
  * No source change upload to rebuild on buildd with .buildinfo files.

 -- Holger Levsen <holger@debian.org>  Sun, 03 Jan 2021 17:49:28 +0100

# Older entries have been removed from this changelog.
# To read the complete changelog use `apt changelog gitpkg`.
