Aigars Mahinovs <aigar...@gmail.com> writes: > On Sun, 30 Jun 2024 at 17:58, Russ Allbery <r...@debian.org> wrote:
>>> The second file consists of a shallow git clone of the repository for >>> the tag that t2u wants to upload, put into an appropriately named >>> tarball. >> Just to double check, to make sure I'm not missing some subtlety, it's >> intentional that this file contains all of the same information as in >> the first file, and the first file is just a subset of this same >> information in a different form? >> In other words, someone could verify the signature on the Git tag in >> this file and then run the git ls-files command on the Git repository >> and get exactly the same information as in the first file, so the first >> file is technically redundant. I can think of some reasons why you >> might want that, but it's a little surprising, so I wanted to make sure >> that's intentional. > Correct me if I'm wrong, but I believe the intention is to have two > technically redundant data points saved into the archive: > 1) checksums of the contents of the shallow copy git tree in the > maintainer work folder (signed by the maintainer) > 2) contents of the shallow copy git tree in the t2u server work folder > (signed by t2u) Oh! Did I misunderstand Joerg's second point entirely? By "the tag that t2u wants to upload," I assumed that meant the tag the uploader signed or, in other words, the state of the tree *before* t2u started doing its work that has the uploader signature attached. If the intent is to have it be the tree *after* t2u has done its work (in other words, the same patches-applied tree with debian/patches/* populated that t2u would push to dgit-repos), that's something a bit different. Personally, I think if we're including a Git bundle anyway, we should create a shallow clone that includes all of those things: the Git tag the maintainer signed, the Git tag that t2u pushed to dgit-repos, and the Git tag of the upstream tree. It's a Git bundle, it's easy to include more things. > The only suggestion I would have here would be to have the shallow git > clone on the t2u side have a variable depth that is selected so that the > commits in the resulting depth are sufficient for the source package > construction, like in case of a rebase workflow you'd need to have git > history deep enough to include all Debian patches and the last upstream > commit. Yes, that's also an interesting idea. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
