Package: git-buildpackage
Version: 0.9.6
Severity: wishlist

When using a pure git workflow (no tarballs involved), as documented in
it is common to configure the “upstream” git remote to be the actual upstream,
whereas the “origin” git remote would be a repository on alioth.

E.g., for the golang-text package, I would configure:
remote “origin” is
remote “upstream” is

Now, when another team member of the pkg-go team uses gbp-clone on the alioth
repository, they won’t get my “upstream” git remote configuration.

This means publishing git repositories is lossy: what I have on my hard disk
does not reflect what other team members will get when they clone the

This makes updating packages way harder than it should be :)

Could we add options to debian/gbp.conf to get an upstream git remote configured
automatically when cloning please?


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel, arm64

Kernel: Linux 4.13.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git-buildpackage depends on:
ii  devscripts             2.17.11
ii  git                    1:2.15.1-3
ii  man-db       
ii  python3                3.6.3-2
ii  python3-dateutil       2.6.1-1
ii  python3-pkg-resources  36.6.0-1

Versions of packages git-buildpackage recommends:
ii  cowbuilder        0.85
ii  pbuilder          0.229
ii  pristine-tar      1.42
ii  python3-requests  2.18.1-1
ii  sbuild            0.73.0-4

Versions of packages git-buildpackage suggests:
pn  python3-notify2  <none>
ii  sudo             1.8.21p2-2
ii  unzip            6.0-21

-- no debconf information
Pkg-go-maintainers mailing list

Reply via email to