Patryk Obara [off-list ref] writes:
The previous implementation of read_graft_line used calculations based
on GIT_SHA1_RAWSZ and GIT_SHA1_HEXSZ to determine the number of commit
ids in a single graft line. New implementation does not depend on these
constants, so it adapts to any object_id buffer size.
To make this possible, FLEX_ARRAY of object_id in struct was replaced
by an oid_array.
There is a leap in logic between the two paragraphs. Your use of
parse_oid_hex() is good. But I do not think moving the array body
to outside commit_graft structure and forcing it to be separately
allocated is necessary or beneficial. When we got a single line, we
know how many fake parents a child described by that graft line has,
and you can still use of FLEX_ARRAY to avoid separate allocation
and need for separate freeing of it.
Understood :) - yes, oid_array is not completely necessary here - and it
gives the wrong impression about usage of this struct.
FLEX_ARRAY will be brought back in v3.
On Thu, Aug 17, 2017 at 11:20 PM, Junio C Hamano [off-list ref] wrote:
Patryk Obara [off-list ref] writes:
quoted
The previous implementation of read_graft_line used calculations based
on GIT_SHA1_RAWSZ and GIT_SHA1_HEXSZ to determine the number of commit
ids in a single graft line. New implementation does not depend on these
constants, so it adapts to any object_id buffer size.
To make this possible, FLEX_ARRAY of object_id in struct was replaced
by an oid_array.
There is a leap in logic between the two paragraphs. Your use of
parse_oid_hex() is good. But I do not think moving the array body
to outside commit_graft structure and forcing it to be separately
allocated is necessary or beneficial. When we got a single line, we
know how many fake parents a child described by that graft line has,
and you can still use of FLEX_ARRAY to avoid separate allocation
and need for separate freeing of it.
--
| ← Ceci n'est pas une pipe
Patryk Obara