Re: Simpler git workflow for packaging with upstreamless repositories
Hi!
On Wed, 27 Nov 2024 at 00:47, <sre4ever@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 git@salsa.debian.org:debian/entr.git (fetch)
origin git@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).
Reply to: