Hello, On Sun 28 Jul 2019 at 07:05pm +01, Rebecca N. Palmer wrote:
> On 28/07/2019 16:18, Ian Jackson wrote: >> What it amounts to is a parallel Merkle tree to the >> git one, just with a different data format and a better hash. > > Not really: it wouldn't need the history tree structure (in Git terms > [0], it would be a tree object not a commit object), and if we use > tar+sha256 [1], it wouldn't need the hash-per-file directory tree > structure either. When I read your first e-mail what I thought you had in mind was just this -- having git-debpush compute a stronger hash of the tree object and add that to the tag metadata, ignoring commit objects. But now I'm struggling to understand the relevance of your discussion of having git-debpush create a .dsc in your second e-mail, if what you're actually talking about is hashing a git tree object. (As an aside, if what you want is to hide .dsc creation from the user but still do it on their machine and upload it, `dgit push-source` is already available.) On Sun 28 Jul 2019 at 04:18pm +01, Ian Jackson wrote: > The downside is that the tag is no longer just a normal signed git tag > with some easy to construct and easy to understand metadata. It will > in practice then not be practical to make this tag other than with > git-debpush (or some other special utility with the same code). This is a downside, but it's not a permanent one -- it goes away if git switches away from SHA-1, which perhaps it is reasonable to expect eventually. It would be good to hear responses to Rebecca's suggestion from those who disagree that it is okay to rely on SHA-1 in the particular way that git-debpush/tag2upload does. -- Sean Whitton