Re: Efficiently storing SHA-1 ↔ SHA-256 mappings in compatibility mode

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

 



"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes:

>> As there are some objects for which we need to carry dynamic
>> information, e.g. "we expect not to have this in our object store
>> and that is fine", which may be set for objects immediately behind
>> the shallow-clone boundary, may need to be cleared when the depth of
>> shallowness changes.  Would it make sense to store these auxiliary
>> pieces of information in separate place(s)?  I suspect that the
>> objects that need these extra bits of information form a small
>> subset of all objects that we need to have the conversion data, so a
>> separate table that is indexed into using the order in the main
>> table may not be a bad way to go.
>
> My plan is to just wire this up to `git gc`.  We'd know what entries are
> potentially disposable (such as shallows) and omit the unneeded entries
> when repacking.

I wasn't talking about when the information is (gathered|consumed),
though.  In response to the request for comments on file format, I
was suggesting to have at least two separte files, one for static
part, and the other for dynamic part, so that the former does not
have to be rewritten all the time.




[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]

  Powered by Linux