gitpkg 0.31 source package in Ubuntu

Changelog

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 <email address hidden>  Sat, 30 Sep 2023 18:12:57 +0930