Robert, Peff and Junio.
Thank you all for your feedback. It's clear now what sort of analysis I should
aim towards.
Thanks,
Zoltan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Thu, Jan 15, 2015 at 03:20:09PM -0800, Junio C Hamano wrote:
> OK, thanks. Let's queue something like this for post 2.3 cycle,
> then.
>
> -- >8 --
> Subject: CodingGuidelines: clarify C #include rules
> [...]
Thanks, this looks good to me.
-Peff
--
To unsubscribe from this list: send the l
Jeff King writes:
> On Thu, Jan 15, 2015 at 10:50:45AM -0800, Junio C Hamano wrote:
>> ...
>> Thoughts? I am not looking forward to a torrent of patches whose
>> sole purpose is to make the existing C files conform to any such
>> rule, though. Clean-up patches that trickle in at a low rate is
On Thu, Jan 15, 2015 at 10:50:45AM -0800, Junio C Hamano wrote:
> So the rule might be:
>
> - The first #include in C files, except in platform specific
>compat/ implementations, must be either git-compat-util.h,
>cache.h or builtin.h.
>
> - A C file must directly include the header fi
Jeff King writes:
> One of our rules is that git-compat-util.h (or one of the well-known
> headers which includes, cache.h or builtin.h) is included first in any
> translation unit.
Perhaps by now we can spell it out a bit more explicitly and update
CodingGuidelines. We have:
- The first #inc
On Thu, Jan 15, 2015 at 05:14:39AM +0100, Robert Schiele wrote:
> Thus doing those kind of brute-force removals generally makes the
> include structure in a project very fragile. The analysis itself you
> did is still useful to identify header files that can potentially be
> removed but removing t
Hi Zoltan,
I can't make a statement for the git project but I consider this kind
of brute-force removal a very problematic approach for languages like
C and C++. The reason for that is simple: Often header files include
other header files since their content depends on those other header
files. Le
Hello there,
Since reading a post [1] about removing some unnecessary #include statements
from a git C source file I've been intrigued to see how many more might be
lurking in the code base.
After a bit of digging around, my brute force approach of 'remove as many
#includes as possible while maki
8 matches
Mail list logo
