Re: [PATCH 02/14] tempfile: a new module for handling temporary files
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 10, 2015, 21:35 UTC
- Message-ID
- <xmqqfv5zi6wk.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <5578A486.1070307@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 24 quoted lines
> On 06/10/2015 07:36 PM, Junio C Hamano wrote: >> Michael Haggerty <mhagger@alum.mit.edu> writes: >> >>> diff --git a/builtin/add.c b/builtin/add.c >>> index df5135b..aaa9ce4 100644 >>> --- a/builtin/add.c >>> +++ b/builtin/add.c >>> @@ -5,6 +5,7 @@ >>> */ >>> #include "cache.h" >>> #include "builtin.h" >>> +#include "tempfile.h" >>> #include "lockfile.h" >>> #include "dir.h" >>> #include "pathspec.h" >> >> It is a bit sad that all users of lockfile.h has to include >> tempfile.h; even when trying to find out something as basic as the >> name of the file on which the lock is held, they need to look at >> lk->tempfile.filename and that requires inclusion of tempfile.h > ... > Hmmm, currently lockfile.h doesn't include tempfile.h. But I think it is > a good idea for it to do so. (I would have done it already but I thought > it was against project policy.)
The project policy is "include what you use, do not rely on others that happen include what you use" with a minor exception for the "must be the first" headers git-compat-util.h (which cache.h and friends include), I think.
If it does not include tempfile.h itself, lockfile.h would be at the mercy of the *.c file that includes it to be able to see the struct it uses; if *.c does not include tempfile.h before lockfile.h, it would break.