Re: [PATCH/RFC v2 04/16] Modify write functions to prepare for other index formats
- From
Thomas Gummerer <t.gummerer@gmail.com>
- Date
- Aug 7, 2012, 12:50 UTC
- Message-ID
- <20120807125039.GB913@tgummerer>
- In-Reply-To
- <7v1ujk3iso.fsf@alter.siamese.dyndns.org>
On 08/05, Junio C Hamano wrote:
Show 28 quoted lines
> Thomas Gummerer <t.gummerer@gmail.com> 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?No I think it makes sense to split them at this point. I'll do it along the lines of what Duy suggested with his patch. [1]
[1] http://thread.gmane.org/gmane.comp.version-control.git/202923/focus=202964