Junio C Hamano <gitster@xxxxxxxxx> writes: > "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> writes: > >> Subject: Re: [PATCH] bulk-checkin: Only accept blobs > > s/Only/only/; > >> 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 ... > >> 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. >> >> Inspired-by: brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> >> Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> >> --- >> >> 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
