Hi! On Wed, 27 Nov 2024 at 00:47, <sre4e...@free.fr> wrote: > > Hi Johannes, > > Le 2024-11-22 12:45, Johannes Schauer Marin Rodrigues a écrit : > > That's what I'm doing. But that works with tarballs not with upstream > > as git. > > If upstream (deliberately, so this will not change) has DSFG-non-free > > content > > in it, then I should not copy that into a git packaging repo that is > > targeting > > main. Removing the problematic parts from the upstream git repos would > > rewrite > > their history, invalidate tags etc, so the result would not be very > > useful > > anymore. Thus, I usually have one directory on my PC with the upstream > > git and > > another with my Debian packaging git. > > For most projects but the larger ones, you could simply add an > `upstream` remote to your local packaging repo. This makes it easier to > diff or look/import specific upstream commits. > > For packaging I usually work with 3 remotes (and no `origin` to avoid > mistakes): > - debian (the team-managed packaging repo on salsa) > - clone (my own clone of the packaging repo as I don't have update > rights on team repos) > - upstream, which is very convenient for their tags, history and cherry > picking.
Note that is your package has the debian/upstream/metadata file, and that file has field "Repository", you can simply run: gbp clone vcsgit:<package> --add-upstream-vcs ..and the resulting repo will automatically have salsa as 'origin' and the real upstream as 'upstreamvcs': ± git remote -v origin g...@salsa.debian.org:debian/entr.git (fetch) origin g...@salsa.debian.org:debian/entr.git (push) upstreamvcs https://github.com/eradman/entr (fetch) upstreamvcs https://github.com/eradman/entr (push) I recommend using 'upstreamvcs' as the upstream origin name to avoid conflicts with tags and branches that start with 'upstream/*' (gbp uses that name automatically).
