On Mon, 27 Feb 2023 at 00:17:41 +0100, Diederik de Haas wrote: > Russ Allbery <r...@debian.org> wrote: > > dgit maintains a history of every package in Debian. > > AFAIK the Debian Xen Team does use dgit (not surprising given dgit's > maintainer (and author?)) ... and that drives me insane. > I'm very sure that is due to me not understanding the concepts/idea/etc, but > I > can't wrap my head around it and it feels *to me* like it constantly rewrites > the (git) history and then does a `git push -f` ... every time.
In most practical maintainer workflows, the Debian patch series fundamentally *does* get rebased every time there is a new upstream release (if not more often), so the various packaging workflows (including at least gbp-pq and git-debrebase, possibly also git-dpm) are ways to reconcile that with wanting the history to be fast-forwarding. dgit is at least partially workflow-agnostic, but as a central design principle it had to choose exactly one representation to be the canonical one, and the one its authors chose was "patches-applied", meaning that any Debian-specific changes to the upstream source code of a package are already pre-applied in the version you get from dgit. Many (perhaps most?) Debian packages in git use the "patches-unapplied" layout compatible with quilt or `gbp pq`, in which the Debian-specific changes in the public VCS only exist in debian/patches and are not pre-applied to the upstream source code (similar to what we used to do in cvs and svn); if using `gbp pq` (as I do), the patches do temporarily get imported into git as a patch-queue branch, which gets rebased, but that patch-queue branch isn't intended to be pushed anywhere. Examples of this include everything maintained by the Perl, Python, GNOME and systemd teams, and many others. For packages that use the common patches-unapplied workflow, the representation in dgit and the representation used by the package's maintainer are not the same (dgit refers to this as "split brain mode"). Packages that I maintain, like dbus and flatpak, might be useful examples for this. The representation you get from Salsa is the way I prefer to work with the package, and the representation you get from `dgit clone` is the way the dgit maintainers would prefer it to be represented. dgit reconciles these two views of the world automatically for me when I upload, so I don't need to do anything differently. See dgit-maint-gbp(7) for more details from the dgit side. Using that workflow is a way I can be nice to dgit users without changing how I interact with debian/patches and without requiring my co-maintainers to do anything differently, so I do that. I suspect that the Xen packaging is using a different workflow that is less focused on the "patches-unapplied" tree than mine is, perhaps based on git-dpm or git-debrebase. smcv