Re: tag2upload (git-debpush) service architecture - draft
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
Reply to: