Hi, I guess I am forced to quote the full message and point out the word trickery going on here:
On Tue, 6 Jan 2026 at 03:04, Ian Jackson <[email protected]> wrote: > > I'm going to address onlhy a few of the most egregious errors. > > Otto Kekäläinen writes ("Re: Include git commit id and git tree id in > *.changes files when uploading?"): > > [Nikolaus Rath] > > > [Otto Kekäläinen] > > > > Debian is actually one of the few distros that is attempting to have > > > > workflows based on importing upstream git repos. Debian currently has > > > > two competing popular systems for doing this: git-buildpackage and > > > > dgit. > > > > > > This statement reveals, even for a casual observer like me, such a > > > fundamental misunderstanding that, in my opinion, it disqualifies you > > > from this discussion. > > tl;dr: Nikolaus is right and Otto is wrong. > > dgit is not principally a competitor to git-buildpackage. Indeed dgit > has git-buildpackage as a dependency! It even has a --gbp mode! Anyone reading this casually please note the use of "not _principally_ a competitor" instead of just "not a competitor". The sentence is true only by sneaking in the word _principally_, at which point it is no longer a response to what I wrote but an intentionally twisted version of it. Anyone who does Debian packaging knows that when you choose what workflow to use and where to keep the packaging git history, you will have to decide if you want to use plain git-buildpackage, layered gbp+dgit, or some of the other dgit workflows such as dgit-maint-debrebase, which makes it possible (with some tradeoffs) to use plain `git rebase` to update patches instead of quilt or `gbp pq` after importing a new upstream version. > You can use *both* gbp and dgit. And indeed, you often should do so. > dgit is not trying to replace gbp. > > > Which of the two points above you feel is not true and you would like > > to have evidence on? The fact that Debian is one of the few in trying > > to import full upstream git histories, or that dgit and > > git-buildpackage are the main tools in Debian for it? > > dgit is not a tool for importing full upstream git histories. Indeed, > dgit is not a tool for importing anything from upstream *at all*. [1] Again here the _full_ is injected into "importing _full_ upstream git histories" instead of just writing "importing upstream git" which is what I actually wrote, and also the clearly correct interpretation of what I wrote in a paragraph saying that Debian is one of the few distros doing this (in contrast to e.g. Fedora or Arch that operate on upstream tarballs without importing anything from upstream git). My original message that was quoted above was in response to Ian writing about that .dcs files are no longer needed and that importing upstream orig tarballs is harmful. Perhaps I should instead of "import upstream" use the term "deposit upstream" as what Ian & Sean seem to use in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110269 when discussing how dgit is archiving upstream tags. However I suspect it does not matter what words I use when the intent is clearly not to have a productive discussion but to verbally punch down on somebody who dares to raise concerns about security / audit trail issues. > Neither is this the primary function of git-buildpackage! "Importing > upstream git histories" isn't even a thing that's hard, that we would > need substantial special software for. It's largely a built-in > function of git. [2] > > Otto Kekäläinen writes ("Re: Include git commit id and git tree id in > *.changes files when uploading?"): > > Hi Ian, > > > Note that tag2upload doesn't make anything worse, with respect to > > > upstream git tags. > > > > I know people who push to dgit directly and avoid using tag2upload > > because of the lack of support for pristine-tar and detached > > signatures in tag2upload. > > Datached (tarball) signatures are not upstream *git tags*. > pristine-tar has nothing to do with *git tags*. I didn't claim tarballs are tags. I was talking about importing/depositing upstream git commits and sources. It is the upstream that has to do with both orig tarballs and git tags if they use both, and many do. Your remark is only intended to ridicule as if somebody wouldn't know the difference. > (We have already said repeatedly that we want to support pristine-tar, > and that we know it is a blocker for some people, so you're > derailing.) > > Ian. > > [1] Importing into Debian that is. If you are downstream of Debian, > then dgit can be a way of importing things *from* Debian. > > [2] Filtering out things that we don't want to include in our git > history may need some special handling, and of course management of > tags and branches is relatively simple, but something that tools like > git-buildpackage can help automate. None of this is anything that > dgit does. > > -- > Ian Jackson <[email protected]> These opinions are my own. > > Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, > that is a private address which bypasses my fierce spamfilter. Ian, you have now in two messages done a personal attack by labelling what I am or telling other people how to treat me, both in very negative ways. You have also attempted to weaponize the Community Team against me even though I am clearly the underdog here being attacked on by you and your collaborator. This makes me feel threatened. I hope you stop now, and I do not want to continue this any further on debian-devel. What comes to design discussions about having git commit ids and tree ids tracked in the build artifacts, I will continue them elsewhere with other people, as I feel that your and Sean's responses here are aimed to shut down discussion instead of collaborative brainstorming on how to best achieve the suggested idea.
