When I work on other (teams) packages, it is, most of the time, because
I need a lib to be updated to a new version to be able to update
another package.

It would be great to have a simple generic way to update a package cloned with "dgit clone".

    $ dgit clone golang-github-xenolf-lego
    canonical suite name for unstable is sid
    starting new git history
    last upload to archive: NO git hash
    using existing golang-github-xenolf-lego_3.2.0.orig.tar.xz
    using existing golang-github-xenolf-lego_3.2.0-2.debian.tar.xz
    dpkg-source: info: extracting golang-github-xenolf-lego in golang-github-xenolf-lego-3.2.0
    dpkg-source: info: unpacking golang-github-xenolf-lego_3.2.0.orig.tar.xz
    dpkg-source: info: unpacking golang-github-xenolf-lego_3.2.0-2.debian.tar.xz
    synthesised git commit from .dsc 3.2.0-2
    HEAD is now at 8a3152a minor consistency correction so our disable-provider patching work.
    dgit ok: ready for work in golang-github-xenolf-lego
    $ cd golang-github-xenolf-lego/
    $ gbp import-orig --uscan
    gbp:error:
    Repository does not have branch 'upstream' for upstream sources. If there is none see
    file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT
    on howto create it otherwise use --upstream-branch to specify it.
    $ git remote add -f upstream https://github.com/xenolf/lego.git
    Updating upstream
    remote: Enumerating objects: 1, done.
    remote: Counting objects: 100% (1/1), done.
    remote: Total 14653 (delta 0), reused 1 (delta 0), pack-reused 14652
    Receiving objects: 100% (14653/14653), 11.22 MiB | 6.30 MiB/s, done.
    Resolving deltas: 100% (8189/8189), done.
    From https://github.com/xenolf/lego
    ...
    $ gbp import-orig --uscan
    gbp:error:
    Repository does not have branch 'upstream' for upstream sources. If there is none see
    file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT
    on howto create it otherwise use --upstream-branch to specify it.
    $ git remote add -f origin https://salsa.debian.org/go-team/packages/golang-github-xenolf-lego.git
    Updating origin
    remote: Enumerating objects: 1293, done.
    remote: Counting objects: 100% (1293/1293), done.
    remote: Compressing objects: 100% (700/700), done.
    remote: Total 1293 (delta 588), reused 1233 (delta 541), pack-reused 0
    Receiving objects: 100% (1293/1293), 647.18 KiB | 759.00 KiB/s, done.
    Resolving deltas: 100% (588/588), done.
    From https://salsa.debian.org/go-team/packages/golang-github-xenolf-lego
     * [new branch]      master         -> origin/master
     * [new branch]      pristine-tar   -> origin/pristine-tar
     * [new branch]      upstream       -> origin/upstream
     * [new tag]         upstream/3.2.0 -> upstream/3.2.0
     * [new tag]         debian/0.3.1-1      -> debian/0.3.1-1
     * [new tag]         debian/0.3.1-2      -> debian/0.3.1-2
     * [new tag]         debian/0.3.1-3      -> debian/0.3.1-3
     * [new tag]         debian/0.3.1-4      -> debian/0.3.1-4
     * [new tag]         debian/0.3.1-5      -> debian/0.3.1-5
     * [new tag]         debian/2.7.2+dfsg-1 -> debian/2.7.2+dfsg-1
     * [new tag]         debian/3.2.0-1      -> debian/3.2.0-1
     * [new tag]         debian/3.2.0-2      -> debian/3.2.0-2
     * [new tag]         upstream/0.3.1      -> upstream/0.3.1
     * [new tag]         upstream/0.4.1      -> upstream/0.4.1
     * [new tag]         upstream/2.7.2+dfsg -> upstream/2.7.2+dfsg
    $ gbp import-orig --uscan
    gbp:error:
    Repository does not have branch 'upstream' for upstream sources. If there is none see
    file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT
    on howto create it otherwise use --upstream-branch to specify it.
    $ git checkout upstream
    upstream
    Branch 'upstream' set up to track remote branch 'upstream' from 'origin'.
    Switched to a new branch 'upstream'
    $ git checkout pristine-tar
    Branch 'pristine-tar' set up to track remote branch 'pristine-tar' from 'origin'.
    Switched to a new branch 'pristine-tar'
    $ git checkout dgit/sid
    $ gbp import-orig --uscan
    gbp:info: Launching uscan...
    uscan warn: No files matched excluded pattern as the last matching glob: vendor
    gbp:info: Using uscan downloaded tarball ../golang-github-xenolf-lego_4.1.0.orig.tar.xz
    What is the upstream version? [4.1.0]
    gbp:info: Importing '../golang-github-xenolf-lego_4.1.0.orig.tar.xz' to branch 'upstream'...
    gbp:info: Source package is golang-github-xenolf-lego
    gbp:info: Upstream version is 4.1.0
    gbp:info: Successfully imported version 4.1.0 of ../golang-github-xenolf-lego_4.1.0.orig.tar.xz

Success!

It would be super nice to have "dgit clone" set up all the branches
(upstream, pristine-tar sometimes) and remotes (upstream, origin), so
that "gbp import-orig --uscan" works out of the box. Or to have a
generic "dgit update-package" to do all these steps.

Hi.

Félix Sipma writes ("Bug#974903: dgit: add a generic way to update a package to a new upstream version"):

Yes.
of assumptions about the way the package git repository is managed,
and what workflow the team uses.  The workflow and git branch
structure you are relying on is common but by no means universal.

Unfortunately I don't think it is possible to do the right thing in
the completely general case.  It may, however, be possible to
recognise this common structurem and work with it.[1]

I'm kind of hesitant to do this in /usr/bin/dgit.  It's rather outside
dgit's existing competences and I wouldn't like to add a lot of
assumptions to dgit.

I think this would perhaps be best done as a separate script.  Perhaps
it could live in devscripts, but I would be very happy to host it in
src:dgit.

Hosting it in src:dgit would allow/require you to fit its test cases
into the existing dgit test framework (which might be a boon or a
bastard, depending on your point of view).

You might also want to check out
https://wiki.debian.org/GitPackagingSurvey
(see the note about formatting - you will want to log into the wiki
and set your theme to Classic).

Realistically I'm afraid I'm not likely to have effort myself to work
on this idea of yours, but I'm happy to advise, review, enable etc.
Beware of getting too enthusiastic or you may find I invite you to be
a co-maintainer :-).

Regards,
Ian.

[1] Thsi would have been much easier to do automatically if my
tag2upload scheme had not been blocked by ftpmaster.