Re: Pack files, standards compliance, and efficiency

From: Duy Nguyen <pclouds@gmail.com>
Date: Jun 5, 2015, 13:24 UTC
Message-ID: <CACsJy8C6E0orN1a6WbkFCiyBtfp94y4XMLS3-i=_6s4WADicCw@mail.gmail.com>
In-Reply-To: <20150605103639.GB19033@peff.net>

On Fri, Jun 5, 2015 at 5:36 PM, Jeff King <peff@peff.net> wrote:

Show 10 quoted lines

> On Fri, Jun 05, 2015 at 05:14:25PM +0700, Duy Nguyen wrote:
>
>> I'm more concerned about breaking object_id abstraction than C
>> standard. Let's think a bit about future. I suppose we need to support
>> both sha-1 and sha-512, at least at the source code level.
>
> I think that's going to be a much bigger issue, because we are casting
> out of a defined, on-disk data structure here. So I'd rather defer any
> code changes around this until we see what the new data structure (and
> the new code) look like.

Yeah.. I don't have a clear idea what it would look like either. What I didn't think of is this object_id may turn around and influence how new on-disk format looks like, to make it easier to work with object_id. So there's an option..

Show 12 quoted lines

>> That might make casting tricky. Maybe we should deal with it now
>> instead of delaying because if the final solution is vastly different,
>> we may be redoing this conversion again. In any case, if we cast, we
>> should make it grep-able (maybe hide the casting in a macro so we can
>> grep the macro's name) so we can examine them when the time comes for
>> us to move away from sha-1.
>
> I think that is sensible. Something like:
>
>   #define SHA1_TO_OBJID(sha1) ((struct object_id *)sha1)
>
> would probably be a good start.

Yep.

-- 
Duy