Re: [PATCH v3 05/14] Change fetch_pack() and friends to take string_list arguments

[Jeff King <peff@peff.net>]

On Mon, Sep 17, 2012 at 03:10:07PM -0700, Junio C Hamano wrote:

> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
> > But how far should this policy be taken?  It seems to me that strict
> > adherence to the policy would dictate that *.h files should *never*
> > include other git project files.
> 
> I wouldn't call that a "policy".  It's something we think about when
> adding a new "#include" to see if it is worth adding and/or if it is
> the right place to add it to reduce code churn.
> 
> As I said, what policy to pick and stick to is open to discussion,
> and I wanted to leave it outside the scope of this series.  As it
> has been cooking in 'next', I do not think it is worth reverting the
> inclusion of "string-list.h" to delay this topic.  It is something
> that can and should be cleaned up when we decide to pick the
> inclusion policy and enforce it.  If we choose to go in the other
> direction, we would end up adding it back, so let's keep it as-is
> for now.

I will admit that I usually follow the opposite policy of what you have
suggested, and include dependent headers in the .h files. Mostly just
because it makes things simpler for the user of the header file, and
there aren't really downsides (yes, you can have weird dependency-order
issues, but in practice those are rare, and they generate very obvious
compile-time errors).

What I think would be much more productive is breaking apart gigantic
includes like cache.h into more reasonable modules, which would mean
less frequent recompilation when an uninteresting part of the header
changes. But git is reasonably fast to compile as it is, so I have never
quite decided that it is worth the human effort to go in that direction.

-Peff