On Sunday, 26 February 2023 22:38:51 CET Adrian Bunk wrote: > On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote: > > On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote: > >... > > > > > For anything in Debian, the package sources in Debian would not > > > disappear when a repository (or salsa) disappears. > > > > 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? > > > > To use an analogy: I'd like that not only the 'destination' is preserved, > > but also the lead up to the destination. > > What goes into the Debian archive is based on tarballs and quilt patches. > Nothing is stored there except the files you upload. Thanks, I thought/'feared' so. > But what do you expect to get from the git history? > > There is no requirement that any history in addition to what is in > the Debian archive exists at all, or any guarantee that what is in > some git tree somewhere is actually the same as what is in the > Debian archive. And git history might just be one commit per upload. > > I would rather like to see people write useful changelog entries > that will still be useful in 25 years instead of > * New upstream version (Closes: #1234567, #1234568, #1234569, ... > or > * Add R³ > than hoping that git metadata would contain anything more useful > than that for such packages. What you described and what I mostly see on changelog entries is: What was changed. What I rarely see is *why* I'm a big proponent of the following git commit structure, which then automatically becomes the git history: primary commit msg: what has changed secondary commit msg: why that change was made including context, deliberations made during that change/commit and alternative solutions considered and why the committer didn't choose for those. The secondary commit msg can be LONG and I like that as it also shows the author/committer pays attention to such things. The (upstream) kernel commit history is a treasure trove of excellent commit messages. The reason that I'm such a proponent of that is that 3 weeks or 3 months from now, there's a reasonable chance that you (the author/committer) does no longer remember the details of that commit. In 3+ years that will be close to 0. AFAIK actual mind reading does not exist, so someone else surely wouldn't know. I've already encountered several cases where the commit was 10+ years old and the commit msg what "Disable setting X" and looking at the diff, I can see the X was indeed disabled. But nothing more. But now I want to enable setting X. But I have no context to know why that would be a bad idea, or actually a good idea *now*, or what will break as a consequence of my enabling X. All I can do is enable X and keep an eye out for bug reports. I think that's what you want to achieve with 'better' changelogs is something similar. I think the git commits are a better place as it's easier to make finer grained distinctions and it's more directly linked to the changes. FTR: I don't *expect* to see those extended commit messages in those old SVN repos, but I do hope I can at least derive _some_ information from the various commits itself. When I was using my own SVN repo I started doing that and I know that I benefited from that a couple of months later. I should have a backup of that somewhere and I'm quite curious if I restore it (and convert it to git) if I can still construct enough detail/history/context from those commit msgs. (As described in the debian-qa ML post, that repo should be 15+ y/o ?) Cheers, Diederik
Attachment:
signature.asc
Description: This is a digitally signed message part.