Re: Include git commit id and git tree id in *.changes files when uploading?
Hi,
On 12/19/25 23:16, Adrian Bunk wrote:
And at that point there is no reason left for the legacy tarball format
we are currently using.
A modern architecture would be that a signed git tag is a source package,
and the official buildds are integrated into the git hosting CI.
IMO it would make more sense to upload git bundles instead of tarballs,
that way it would still be trivial to mirror and archive all the source
packages. This would also allow including the signed tag itself inside
the bundle, and does not impose connectivity requirements on the buildd,
or service availability requirements on salsa admins.
We would still need to address the open questions for git based archives:
1. how do we represent patches to upstream sources: as commits
(metadata) or as files (data)?
2. how do we represent the changelog: as commits (metadata) or as files
(data)?
3. how do we handle excluded files?
4. how do we represent that we're effectively rebasing the Debian patch
stack whenever a new upstream version is introduced?
5. how do we represent "new upstream" vs "rebased Debian patches" vs
"collaboration inside a team" (all three generate commits)?
... and probably others, this list is not exhaustive
With tarballs, these had easy answers:
1. patches go to debian/patches inside the .debian.tar.*
2. changelog goes to debian/changelog inside the .debian.tar.*
3. excluded files are removed from the tarball, and the version number
adjusted to indicate this
4. the rebased patch stack is associated with the particular source
package version
5. the archive does not have to care: a new upstream is when the
upstream version number changes, a new Debian version can have a new
patch stack, and collaboration commits (especially those that don't even
compile) aren't archived.
Changing the format so that metadata can be represented as metadata
would be a major step forward, but I don't see that happening currently:
we're effectively using git only as a network filesystem for
collaboration, then expressing the Debian specific metadata as data
inside git, and this mismatch means that we need to use well-known
branch and tag names to identify what is what.
One possible approach would be to introduce trailers in commit messages
that distinguish their role for packaging, but it feels very xkcd 927.
Simon
Reply to: