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
> <sandals@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