Re: Git branch layout for packages requiring DFSG-cleaning

Hi,

> On Thu, 20 Aug 2026, at 21:45, Marcin Owsiany wrote:
> > I found some conflicting information about the recommended branch layout
> > and I'm wondering why that is (mistake? outdated recommendation) and
> > what folks tend to use in practice and why.
>
> My approach:
> If the upstream files I’m removing while repacking are not redistributable, I don’t add them to Git at all, even if they’re present in the upstream’s Git branch. I only import filtered tarballs.
> If the upstream files are legally okay, depending on whether it’s tarballs or a Git branch, I sometimes import them as upstream/latest or upstream/{master,main}. Cleaned sources go onto upstream/dfsg, into which I merge the unfiltered upstream branch: doing that tells Git these files can be removed upon the next merge.
> For a bunch of packages, I choose the first approach because I don’t care about the upstream Git or tarballs at all.

Somewhat of a tangent, but I think it is already pretty well
established that hosting a copy of upstream git on salsa.debian.org is
acceptable, regardless of what files upstream has in their git HEAD or
history. Only the stuff we upload to Debian archives is what we
consider "redistribution".

Also, the branch upstream/latest should represent the upstream source
that was imported into Debian. If debian/copyright:Files-Exclude is
defined, this branch and the orig tarball created from this will be
automatically filtered.

If upstream uses branch 'master' or 'main' for development and you
want to have that in your git repo as well, just use the branch names
'master' or 'main'. I don't see any need in renaming them to
upstream/{master,main}. I don't think upstream git tags should be
renamed either. The whole point of DEP-14 is to define a unique
Debian-only namespace scheme that is very unlikely to clash with
upstream naming conventions for any project, and thus allow upstream
release tags and branch co-exist in the same repo as Debian packaging
with debian/*, upstream/*, pristine-tar etc branches and tag names.

If the above is perplexing, the diagrams at
https://optimizedbyotto.com/post/debian-source-package-git/ may do a
better work in explaining the git scheme. Another relevant one where I
summarize the "best practice" in my opinion for any new Debian package
is at https://optimizedbyotto.com/post/debian-packaging-from-git/. Old
packages can also be converted into following the DEP-14 convention,
but that is a longer explanation.