Re: [PATCH/RFC v2 04/16] Modify write functions to prepare for other index formats

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

 



Thomas Gummerer <t.gummerer@xxxxxxxxx> writes:

> -static int ce_write(git_SHA_CTX *context, int fd, void *data, unsigned int len)
> +static int ce_write_v2(git_SHA_CTX *context, int fd, void *data, unsigned int len)
>  {

Mild NAK to name this function with any hint that it is for v2 only.
The type of "data" is not "struct ondisk_index_entry_v2" and this is
just a way to stream data to "fd" while hashing, which is similar in
spirit to what csum-file.c "sha1file'"API does.  Perhaps we may want
to update ce_write() interface to build on top of sha1file API?

At this step in the series, is it too early to split read-cache.c
into two files, move all the v2 specific part to read-cache-v2.c,
and keep static function names like write_index_ext_header() as they
are?  After all, the main dispatch would become

> +int write_index(struct index_state *istate, int newfd)
> +{
> +	if (!istate->version)
> +		istate->version = INDEX_FORMAT_DEFAULT;
> +
> +	return write_index_v2(istate, newfd);
> +}

so read-cache-v2.c would need to export write_index_v2() but the
functions to implement it like ce_write_entry() do not have to be
exposed outside the file, no?
--
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]