Michael Haggerty [off-list ref] 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.
On Mon, Sep 17, 2012 at 03:10:07PM -0700, Junio C Hamano wrote:
Michael Haggerty [off-list ref] writes:
quoted
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