On Wed, 22 May 2024 at 21:55:15 +0200, Paul Gevers wrote:
On 21-05-2024 1:08 p.m., Sean Whitton wrote:
PS: I've always wondered if the dgit server shouldn't track history, even if
uploads don't happen via it. A dgit clone could (should?) already provide available history, even if no upload happened via it yet.
Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's history. So it sort of does this. We could make it do more.
Huh. Than my workflow hides this. All I'm often seeing is just the tar content represented in a commit, the latest Debian packing in another and
the merge of these two (if I recall and describe what I recall correctly). I always thought that dgit clone generated that on my computer if there was no git content on the dgit server. I'll try to remember this next time I run my no-changes-source-only upload script.
I believe the 3-commit orig + packaging + merge (vaguely similar to what
you would get from `gbp import-dsc` into an empty repository) is what you
get if the most recent upload was not made with dgit, and therefore does
not have the Dgit field in its `apt-cache showsrc` record.
This means that dgit might know what repository the maintainer uses to
store their idea of the packaging (it can get this from Vcs-Git), but it
does not know which specific commit in that repository is the equivalent
of what's in the archive, or which of the various possible workflows
the maintainer uses to get from that commit to an uploadable .dsc - and therefore it doesn't have a particularly good way to glue the maintainer's
git history into the ancestry of the commit that it generates.
If you look at GNOME team packages, packages that were most recently
uploaded by me generally do have a Dgit field[1], and packages that were
most recently uploaded by another team member often do not. At the time
of writing, gtk4/unstable was uploaded with dgit, but gtk4/experimental
was not - that might make a useful comparison?
I use the dgit-maint-gbp workflow myself, so the dgit history contains a transformation from the format used in our team VCS, which dgit calls the "maintainer view" (in the GNOME team this is gbp-style patches-unapplied)
to dgit's canonicalized view (which is patches-applied, because that's
what the designers of dgit have chosen to canonicalize into).
A nice thing about dgit-maint-gbp is that my co-maintainers don't need
to agree with me, and can continue to use gbp + debsign + dput, or
quilt + debsign + dput, or construct patches in any other compatible way:
as long as we agree on the desired source tree, we can interoperate.
smcv
[1] except for -security uploads
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)