[PATCH] bulk-checkin: Only accept blobs

Junio C Hamano [off-list ref] writes:

"Eric W. Biederman" [off-list ref] writes:

quoted

Subject: Re: [PATCH] bulk-checkin: Only accept blobs

s/Only/only/;

quoted

As the code is written today bulk_checkin only accepts blobs.  When
dealing with multiple hash algorithms it is necessary to distinguish
between blobs and object types that have embedded oids.  For object
that embed oids a completely new object needs to be generated to
compute the compatibility hash on.  For blobs however all that is
needed is to compute the compatibility hash on the same blob as the
storage hash.

All of the above is understandable, but ...

quoted

As the code will need the compatiblity hash from a bulk checkin, remove
support for a bulk checkin of anything except blobs.

... I am not sure what the first half of this sentence is saying.

I mean the code will need to compute both the SHA-1 and the SHA-256
oid of the object being checked in.

What I left implied is that for blobs this is straight forward because
the object header and content are the same in both cases, and we just
need calls from the compatible hash algorithm to allow computing both
SHA-1 and SHA-256 simultaneously.

For commits, trees, and tags the entire objects must be walked before
the size of the compatible object is known.  The size of the compatible
object appears in the compatible object header.  Which means that for
commits, trees, and tags their compatible object must be computed
before their compatible hash can be computed.

Computing all of that in two passes is not what streaming interface
is about.

Do you mean something like:

    The function takes "enum object_type" and pretends that it could
    stream trees and commits, if we wanted to interoperate with
    multiple hash algorithms, there are a lot more information than
    just the contents and object type needed.  A tree object needs
    "compatibility hash" (i.e. the hash computed for the other hash
    functions) for objects the tree contains, a commit object
    likewise needs "compatibility hash" for its tree and its parent
    commits.  IOW, the existing interface into the functions this
    patch touches is way too narrow to be useful for object types
    other than blobs.

perhaps?  I agree with the conclusion that the functions on the
callchain involved in the bulk-checkin feature can safely be
limited to handle blobs in the current code (and I have my reasons
to think why it is not regressing the interface), but it makes me
feel uneasy that I am not quite sure what your reasoning is.

The interface is wide enough, as we can safely assume that all
objects a commit, tag, or tree would refer to already have both
their SHA-1 and SHA-256 oid computed.

The problem is that it would take a 2 passes over a tree, commit, or tag
object to compute both it's SHA-1 oid and it's SHA-256 oid.

quoted

Inspired-by: brian m. carlson [off-list ref]
Signed-off-by: "Eric W. Biederman" <redacted>
---

Apologies to anyone who has seen this before.  The last time I sent
this patch out it seems to have disappeared into a black hole so
I am trying again.

I do not know if vger is dropping your messages, but I haven't seen
this on https://lore.kernel.org/git/ archive, so I'll quote from the
message I am responding to everything without omitting anything, to
let others who may find out about this patch via my response.

I don't see the messages at vger either.  So I am going to try this
conversation from my gmail address and see how well that works.

Eric