From: Eric Wong Date: Mon, 10 Apr 2017 14:28:50 GMT Subject: Re: [PATCH v3 4/4] convert: add "status=delayed" to filter process protocol Message-ID: <20170410142850.GA23068@starla> In-Reply-To: <16331164-8E8C-4CDA-B319-AB8092BD7188@gmail.com> Lars Schneider wrote: > > diff --git a/convert.h b/convert.h > > index 82871a11d5..da6c702090 100644 > > --- a/convert.h > > +++ b/convert.h > > @@ -42,6 +42,11 @@ extern int convert_to_git(const char *path, const char *src, size_t len, > > struct strbuf *dst, enum safe_crlf checksafe); > > extern int convert_to_working_tree(const char *path, const char *src, > > size_t len, struct strbuf *dst); > > +extern int async_convert_to_working_tree(const char *path, const char *src, > > + size_t len, struct strbuf *dst, > > + void *dco); > > > > I don't like the void pointer here. However, "cache.h" includes "convert.h" and > therefore "convert.h" cannot include "cache.h". That's why "convert.h" doesn't > know about "struct delayed_checkout". You can forward declare the struct without fields in convert.h: diff --git a/convert.h b/convert.h index da6c702090..3fb6b420b2 100644 --- a/convert.h +++ b/convert.h @@ -32,6 +32,8 @@ enum eol { #endif }; +struct delayed_checkout; + extern enum eol core_eol; extern const char *get_cached_convert_stats_ascii(const char *path); extern const char *get_wt_convert_stats_ascii(const char *path); @@ -44,7 +46,7 @@ extern int convert_to_working_tree(const char *path, const char *src, size_t len, struct strbuf *dst); extern int async_convert_to_working_tree(const char *path, const char *src, size_t len, struct strbuf *dst, - void *dco); + struct delayed_checkout *dco); extern int async_query_available_blobs(const char *cmd, unsigned long **delay_ids, int *delay_ids_nr); extern int renormalize_buffer(const char *path, const char *src, size_t len, > > I just realized that I could move "struct delayed_checkout" and "enum ce_delay_state" > definition from "cache.h" to "convert.h" to solve the problem nicely. > But yeah, maybe you can reduce cache.h size, too :) > Any objection to this approach? >