Re: ab/object-file-api-updates

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

 



Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:

> On Tue, Mar 01 2022, Junio C Hamano wrote:
>
>> * ab/object-file-api-updates (2022-02-25) 12 commits
>>  - object-file API: pass an enum to read_object_with_reference()
>>  - object-file.c: add a literal version of write_object_file_prepare()
>>  - object-file API: have hash_object_file() take "enum object_type"
>>  - object API: rename hash_object_file_literally() to write_*()
>>  - object-file API: split up and simplify check_object_signature()
>>  - object API users + docs: check <0, not !0 with check_object_signature()
>>  - object API docs: move check_object_signature() docs to cache.h
>>  - object API: correct "buf" v.s. "map" mismatch in *.c and *.h
>>  - object-file API: have write_object_file() take "enum object_type"
>>  - object-file API: add a format_object_header() function
>>  - object-file API: return "void", not "int" from hash_object_file()
>>  - object-file.c: split up declaration of unrelated variables
>>
>>  Object-file API shuffling.
>>
>>  Needs review.
>>  source: <cover-v3-00.12-00000000000-20220204T234435Z-avarab@xxxxxxxxx>
>
> Jiang Xin (whose git-unpack-objects series at [1] depends on this) has
> looked this over & acked it at [2].
>
> 1. https://lore.kernel.org/git/cover-v10-0.6-00000000000-20220204T135538Z-avarab@xxxxxxxxx/
> 2. https://lore.kernel.org/git/CANYiYbFZN=mvcxRT4Cf4Gzao89KR2UjMJXnJM63S2zAtbD32Jg@xxxxxxxxxxxxxx/

I've read this one again.  It was mostly a pleasant read and the
endgame state that use object type constant instead of a typename
string as much as possible (i.e. the only exception is the
"literally" stuff that was meant for debugging, which has to take a
possibly bogus typename string) is excellent.





[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