Re: [PATCH 0/2] config includes, take 2

From: Jeff King <peff@peff.net>
Date: Feb 6, 2012, 10:16 UTC
Message-ID: <20120206101630.GA5394@sigill.intra.peff.net>
In-Reply-To: <20120206100622.GC4300@sigill.intra.peff.net>

On Mon, Feb 06, 2012 at 05:06:22AM -0500, Jeff King wrote:

Show 14 quoted lines

> > If that is the goal, all you have to record is the "include stack"
> > context that caused the currently-being-included file to be read and
> > make sure that the currently-being-included file didn't appear earlier
> > on the stack.  The fact that the same file was included earlier (but
> > not as part of the same include chain) needn't be considered an error.
> 
> I considered this, but decided the complexity wasn't worth it,
> especially because getting it accurate means cooperation from
> git_config_from_file, which otherwise doesn't know or care about this
> mechanism. Instead I keep a simple depth counter and barf at a
> reasonable maximum, printing the "from" and "to" files. Yes, it's not
> nearly as elegant as keeping the whole stack, but I really don't expect
> people to have complex super-deep includes, nor for it to be difficult
> to hunt down the cause of a cycle.

Oh, one other thing: to detect cycles, you have to use a canonical version of the filename for comparisons. That makes the existing stack that git_config_from_file keeps useless. Using real_path is hard, because it will die() if some path components don't exist. Using absolute_path is a reasonable compromise, but it can actually miss some cycles if they involve symbolic links.

Not insurmountable if you can accept teaching git_config_from_file to real_path() each file it reads. But again, it ends up getting complex for IMHO not much gain. A stupid depth counter can't show you a stack trace (and it may have false positives), but it's dirt simple and probably good enough.

-Peff