I noticed that git-debpush doesn't push the upstream branch to salsa
(for a typical gbp-style package) which can (and, in retrospect, has)
lead to troubles for teams using this laylout.

Last example:

#v+
% git debpush --gbp --upstream=upstream/0.44
git-debpush: checking state at git@salsa.debian.org:perl-team/modules/packages/libpdf-reuse-perl.git
git-debpush: check failed: unneeded --gbp on command line, would have autodetected it ('superfluous-quilt-mode' check)
git-debpush: proceed anyway? (y/N) y
git-debpush: making signed tag debian/0.44-1
git-debpush: pushing to git remote origin
Enumerating objects: 158, done.
Counting objects: 100% (141/141), done.
Delta compression using up to 4 threads
Compressing objects: 100% (77/77), done.
Writing objects: 100% (117/117), 42.27 KiB | 10.57 MiB/s, done.
Total 117 (delta 52), reused 74 (delta 27), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (52/52), completed with 11 local objects.
remote:
remote: To create a merge request for pristine-tar, visit:
remote:   https://salsa.debian.org/perl-team/modules/packages/libpdf-reuse-perl/-/merge_requests/new?merge_request%5Bsource_branch%5D=pristine-tar
remote:
To salsa.debian.org:perl-team/modules/packages/libpdf-reuse-perl.git
   682fbec..94af040  master -> master
   a4c25ad..1e6b483  pristine-tar -> pristine-tar
 * [new tag]         upstream/0.44 -> upstream/0.44
 * [new tag]         debian/0.44-1 -> debian/0.44-1
#v-

The master and pristine-tar branches are pushed, as well as the
upstream/ and the new debian/ tag but that's it.

/*
As a side note: _Asking_ if I want to proceed because my "--gbp" is
the same as what git-debpush detected itself is a bit annoying. An
info is fine.
*/


Cheers,
gregor
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmps4bZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZbwA//QWyjlhPioGCjYWVPH+SqoMxeggEEVWSqHyxbEoD3BH97E6GUyJayk8TE
f/n1X0kzmGnRvv/+PyitWhDPEwSD3qHqXYN00C41xXVuqBCGiIqMs+qP/3gilMri
KXF+tt5Uicn7s0mQ8j3d7YYRv9mKkUd3c8XU0heIOa77DaKEtkOIcurJiPqJKWVV
HOK9Q9nq2EwB5Nb0NFkxr6YcE6x6zqpVyglnVvwTbnfsjk4DH/rilcvg0AZdVbWk
CFkcIAL8WXKq53yOq14+WJ3LDoF7twBGlvufPOg8KAZ9at2vcmUR81YZhfvHVcBB
AK8c3koKwP3qJAsx5/rBdW7fa2pBMr7kKZTp2EYzgRRoqYYD6QuhfDtoTmzcDdF7
sjmFsFy3eVMNdkebLWkhOdP4aPouPzJWhWWyXbLnN0eLCt4tggRuMtpDSwGrYGPv
67Weh/Z7gzO/Uu4qxeOpk0pW7OC3ecSbXYgWj5P09hkDqOWYC2n8vWps3JwBIqXA
mTF28CjXIz528B+YTOTAiDeDrqkkZSn17/3KBubiupDgwuAFCM4cSjHH49QD6Uyu
H8+4XhNr5RGhFEgcQzFkZfImEPkBC2KGHRyz9h6S0W3Ss6Veq5YA+BRdciLRk49O
i8H79jgl7nA05d7ZhJhrDy/Kx9+M8q5TFJhnVFVYHcUDWXZp/t4=
=Fhvl
-----END PGP SIGNATURE-----

gregor herrmann writes ("Bug#1143205: git-debpush: should push upstream branch (for gpb repos)"):
...

Hrm.  I see your point.  I thin we need to think, though, about when
this should happen.

How about this for the conditions:

 * upstream tag that we used for the upload is named upstream/...
   (indicating use of a separate Debian upstream branch)

 * upstream tag points to a commit that's on the local upstream
   branch which is fast forward from the remote upstream branch
   (or remote upstream branch is absent).
   Ie, pushing the upstream branch would make the tagged commit
   reachable from the upstream branch.

I will clone the bug for this and then reply in the clone,
for reasons that will become clear...

Ian.

Thanks.

Right

Sounds good at first glance.


Is it any help that git-debpush detects or is told (or both) that
it's acting in a gbp-layout repo? I.e. can it then know about the
branches and just push them?


Cheers,
gregor

gregor herrmann writes ("Re: Bug#1143205: git-debpush: should push upstream branch (for gpb repos)"):

No, because whether the repo is patches-unapplied (ie, what --gbp
means), is largely orthogonal to the upstream handling (gbp
import-orig vs git merge).

It's entirely possible to use gbp import-orig and then git-debrebase.
(in which case --quilt=linear but git-debpush should push upstream)
Or gbp pq on top of a plain git import from upstream (in which
case --quilt=gbp but the local and remote upstream branches might be
something entirely else).

Ian.

Oh, right!


Cheers,
gregor

(moving this subthread to the bug where the rest of this conversation
is)

Sean Whitton writes ("Re: [PATCH FYI 3/5] git-debpush: Push refs/heads/upstream too, when appropriate"):

This is an attempt to distinguish the following scenarios:

 1. We are working off upstream git.  The upstream git tag named in
    the debian/ tag2upload tag references an upstream commit directly.

    In this sceanrio, there isn't necessarily any branch on salsa that
    corresponds to the upstream git branch.  Normally, the upstream
    git is simply remote tracking branches on each maintainer's
    machine.  New git upstream versions are obtained from upstream.

    There is no need to push upstream git history to salsa as a
    branch; the tag is sufficient.

    The user may have create a local `upstream` branch but its
    contents are not well-defined and pushing it to salsa would be
    surprising.

 2. The maintainer is using gbp import-orig.

    The "upstream" branch is not actually what we would think of as an
    upstream branch.  It's a branch of Debian-specific tarball
    imports.  It may or may not be based on upstream history, but it
    is a genuine, separate, fast-forwarding, branch, whose canonical
    location is the salsa upstream branch.

    In this case, gbp import-orig makes an upstream/ tag.  But pushing
    that is not sufficient because a subsequent maintainer wants to
    make their next import fast forward from the previous one.

 3. We're using a git-first workflow, but need to filtering (eg, DFSG
    filtering).

    In this case we probably have a separate upstream branch, where
    the DFSG filtering is done (maybe just by merging from upstream).
    We can't use the upstream tags directly.  Instead we must make
    +dfsg tags, presumably called upstram/... according to DEP-14.

    Updates to the upstream branch ought to be pushed to salsa.

Or to put it another way, the `upstream` branch is part of DEP-14's
ideas about upstream source code handling, just like the
upstream/... tag.

We need to push the upstream branch if it is a separate branch from
plain upstream git history (which one doesn't typically manually
mirror ad-hoc as real branch).

I don't think thsi is completely perfect but ultimately we need to do
a bit of guessing about the user's git branch practices.

Personally I don't think I have any idea what "most packages" do.  The
use of gbp import-orig seems (unfortunately) extremely common, and
that *does* always create these upstream/ tags.

Thanks,
Ian.

We believe that the bug you reported is fixed in the latest version of
dgit, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1143205@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ian Jackson <ijackson@chiark.greenend.org.uk> (supplier of updated dgit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 03 Aug 2026 14:42:35 +0100
Source: dgit
Architecture: source
Version: 16.4
Distribution: unstable
Urgency: medium
Maintainer: Debian tag2upload Delegates <dgit-owner@debian.org>
Changed-By: Ian Jackson <ijackson@chiark.greenend.org.uk>
Closes: 1143205
Changes:
 dgit (16.4) unstable; urgency=medium
 .
   git-debpush:
   * git-debpush: Push refs/heads/upstream too, when appropriate
     [Report from gregor herrmann]  Closes: #1143205.
   * git-debpush(1): Improve description of pushing behaviour.
Checksums-Sha1:
 979c49e6e05be03c3be777e057a270b2717f8035 2533 dgit_16.4.dsc
 9b52f11c484afab2afceb3a8e1f456ea78b99c58 1066705 dgit_16.4.tar.gz
 76b45b4e85902f91c5970b1450b501f123d47b28 1370600 dgit_16.4.git.tar.xz
 ce45ec7af2a2601528e2401caff77264e5c8dcda 17528 dgit_16.4_source.buildinfo
Checksums-Sha256:
 13c005944469611985319456f58d4644bf0bb1c08bd168fff436f82f7d45d113 2533 dgit_16.4.dsc
 3e6e537cd22214c7bd6e172e4824871a4365b1e6956fd7be48a6a9a96d33718e 1066705 dgit_16.4.tar.gz
 73cb0662307fd0f455864a768be21654ba06f9db6d7b307cc1a6992ff67c2572 1370600 dgit_16.4.git.tar.xz
 4ed335457f83eb8fe63f6a0d755dc6603972b80e429ac70db0b3d16598af4a42 17528 dgit_16.4_source.buildinfo
Files:
 fb506ca006b80bdf5ac5c93023f6fcf5 2533 devel optional dgit_16.4.dsc
 ede8f8e0bb8ea5abfa09871d210a5dbd 1066705 devel optional dgit_16.4.tar.gz
 f9b559510ed9f62fc2fe754e57ad1740 1370600 devel optional dgit_16.4.git.tar.xz
 f873608a253255549b6522b44601421b 17528 devel optional dgit_16.4_source.buildinfo
Git-Tag-Info: tag=32d3451ac922011c82da570bef0b4db597df4f7d fp=41638114d132883b25a20ddd47515757d8002456
Git-Tag-Tagger: Ian Jackson <ijackson@chiark.greenend.org.uk>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEN02M5NuW6cvUwJcqYG0ITkaDwHkFAmpwvToACgkQYG0ITkaD
wHne7g//atBmebmVKdoOkQsydVqyrJvYrQZzwdiGOyoyS0Mqzo0AO/Rx7sbueSPD
mn/1azeT725oT4LrdcKQRnkovqUfCnyN03ERoMNSd0m+gbanlf0keZ5yLqFzu4wu
JbGIgfuaA0tFh6CXHnL3E/U1NG/PsGOI78lf51f+vTJtXDFlxhLLy0iUKBFLAK60
33p71LWMp+wt8qsyjoI7uGBBsWswJzr7KehliSHekVkqFO0JlI/yU5QjGMMFoQzY
iXqFCOw96KQjPHf2GwxagAioDpKQjhbcxEJ9UDI14IxP7P7g4fiaU574eBl4+fyR
x7InXvhwXWuOukCxV3VISF9HdItI3u8tzEiLrZOlIY9uKOieYyJMfteXWedD85Wt
PSzNVRUlS1JjZuIXDWFdra0AIHOBRu4/dfMxImOERt5n1Fm20oipylxPZFZhc3Ql
aRZujQe9AGofj4YAlIWmaGATvrKu2L7uwXdSh1lhUuxNQeL4hfzJpwqXk6rAD7gp
bsw7nxgqFUnlYzRBdS8SS2UsVMFqc8a3Onvf8ygIy4jGf4NK5b6q9IQn7qdUQ/rq
V+bGeYBpdXQ96pGon2J6eeCZyKfitREotRP22vujrQ7rRXm18P/epzt2/dkub7Cx
gQUzFFpvX2eZv5kLueKeIvChLjOV6EZ1qBqDctH0a5emg9cE81E=
=ydJ7
-----END PGP SIGNATURE-----

Thanks Ian.

I just had the chance to try with a -1 upload, and can confirm that
all relevant tags and branches (including the upstream branch) have
been pushed (for a gbp-style package).


Cheers,
gregor