On Wed, May 02, 2018 at 05:26:25PM +0200, Duy Nguyen wrote: > On Wed, May 2, 2018 at 2:11 AM, brian m. carlson > <sand...@crustytoothpaste.net> wrote: > > On Tue, May 01, 2018 at 12:22:43PM +0200, Duy Nguyen wrote: > >> While we're abstracting away 20. There's the only 20 left in > >> sha1_file.c that should also be gone. But I guess you could do that > >> later since you need to rename fill_sha1_path to > >> fill_loose_object_path or something. > > > > I'm already working on knocking those out. > > Yeah I checked out your part14 branch after writing this note :P You > still need to rename the function though. I can remind that again when > part14 is sent out.
I've made a note in my project notes. > > Unfortunately, I can't, because it's not an object ID. I think the > > decision was made to not transform non-object ID hashes into struct > > object_id, which makes sense. I suppose we could have an equivalent > > struct hash or something for those other uses. > > I probably miss something, is hashcmp() supposed to stay after the > conversion? And will it compare any hash (as configured in the_algo) > or will it for SHA-1 only? Yes, it will stick around for the handful of places where we have hashes like pack checksums. > If hashcmp() will eventually compare the_algo->rawsz then yes this makes > sense. That's my intention, yes. > > I believe this is the pack hash, which isn't an object ID. I will > > transform it to be called something other than "sha1" and allocate more > > memory for it in a future series, though. > > Ah ok, it's the "sha1" in the name that bugged me. I'm all good then. Also noted in my project notes. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
