Re: Pack files, standards compliance, and efficiency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 5, 2015 at 5:36 PM, Jeff King <peff@xxxxxxxx> wrote:
> 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..

>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]