[please CC me in replies as I'm not subscribed to d-devel] Russ Allbery <rra@debian.org> wrote: > Diederik de Haas <didi.debian@cknow.org> writes: > > Question as I don't know: is that only the package change that gets > > uploaded to the Debian archive, or is there also a place where the (git) > > history of the changes leading up to a new upload gets stored? > > dgit maintains a history of every package in Debian. If you use dgit to > make your upload, that will include the full Git history of the changes, > regardless of where you store your Git repository. If you don't, then it > only has the uploads to work with, so each package upload is a new commit > and the detailed breakdown of the work between those uploads is not > available via dgit. > > But it does provide at least upload-level granularity as a Git history for > every package, even those maintained with no version control system at > all, with the option for each package maintainer of opting into providing > more. I'm not new to git or Debian, but I have ~0 experience with packaging (and I want to change that with id3lib). Therefor I don't have (much) experience with the packaging tools (in general). But 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. I once referenced a patch by number (and a short description iirc) and on the next push, that patch had a different number, thus messing up my commit msg. The most confusing thing for/to me is that it completely rearranges the commit sequence, so I can't follow the changes that happened over time. Right now in https://salsa.debian.org/xen-team/debian-xen/-/commits/master HEAD~30 (and the 2 commits before that) are the most recent (and to me the most relevant), but HEAD~9 was made 8 YEARS ago. I may learn dgit in time, but that'll probably be a (long) while. But as I described in another reply to this thread, the upload-level granularity is mostly useless *to me* as it usually only (tersely) describes the *what*, but not the *why*.
Attachment:
signature.asc
Description: This is a digitally signed message part.