On Mon, Sep 17, 2012 at 03:10:07PM -0700, Junio C Hamano wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html