Jeff King writes:
> 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.
Ideally cache.h should cover what read-cache.c, sha1_
On Mon, Sep 17, 2012 at 03:10:07PM -0700, Junio C Hamano wrote:
> Michael Haggerty 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
Michael Haggerty 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
On 09/10/2012 10:56 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>> diff --git a/fetch-pack.h b/fetch-pack.h
>> index 1dbe90f..a6a8a73 100644
>> --- a/fetch-pack.h
>> +++ b/fetch-pack.h
>> @@ -1,6 +1,8 @@
>> #ifndef FETCH_PACK_H
>> #define FETCH_PACK_H
>>
>> +#include "string-list.h"
>
Michael Haggerty writes:
> Instead of juggling (sometimes called
> ), pass around the list of references to be sought in
> a single string_list variable called "sought". Future commits will
> make more use of string_list functionality.
>
> Signed-off-by: Michael Haggerty
> ---
The earlier bik
Instead of juggling (sometimes called
), pass around the list of references to be sought in
a single string_list variable called "sought". Future commits will
make more use of string_list functionality.
Signed-off-by: Michael Haggerty
---
builtin/fetch-pack.c | 88 +++--
6 matches
Mail list logo
