Subject: Re: [PATCH v3 4/4] convert: add "status=delayed" to filter process protocol

From: Eric Wong <[email-masked]>
Date: Mon, 10 Apr 2017 14:28:50 +0000

Lars Schneider <[email-masked]> 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?
>