From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 16 Feb 2012 20:11:52 GMT
Subject: Re: [PATCH 0/8] config-include fixes
Message-ID: <7v1upuzgfr.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120216080102.GA11793@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> I prepared this on top of what you have queued in jk/config-include.
> However, all of the cleanup is semantically independent of the topic
> (though there are a few minor textual conflicts). If I were re-rolling,
> I would put it all at the front, then squash patch 8 into my prior
> "implement config includes" patch.

Sorry for being late in answering the "revert or build on top" question; I
was mostly offline yesterday afternoon.

>   [7/8]: config: eliminate config_exclusive_filename
>
> This is all cleanup which makes config_exclusive_filename go away. It's
> not strictly necessary for this series, but it's something I've been
> wanting to clean up for a while. And it does fix a few minor bugs (see
> patch 6/8). And the refactoring in 5/8 lays the groundwork for 8/8.
>
>   [8/8]: config: do not respect includes for single-file --list
>
> The actual fix for the regression in my config-include patch.

Thanks.

Looking at the rebased result, it strikes me that with_options version

    Furthermore, by providing a more "advanced" interface, we
    now have a a natural place to add new options for callers
    like git-config, which care about tweaking the specifics of
    config lookup, without disturbing the large number of
    "simple" users (i.e., every other part of git).

perhaps wants to get a pointer to struct config_lookup_options, instead of
us having to add a new parameter to all callsites every time a new need
is discovered.