On Tue, Mar 7, 2017 at 12:47 AM, Jeff King wrote:
> On Mon, Mar 06, 2017 at 02:44:27PM -0800, Stefan Beller wrote:
>
>> > +static int include_condition_is_true(const char *cond, size_t cond_len)
>> > +{
>> ...
>> > +
>> > + error(_("unrecognized include condition: %.*s"), (int)cond_len,
>>
On Mon, Mar 06, 2017 at 02:44:27PM -0800, Stefan Beller wrote:
> > +static int include_condition_is_true(const char *cond, size_t cond_len)
> > +{
> ...
> > +
> > + error(_("unrecognized include condition: %.*s"), (int)cond_len,
> > cond);
> > + /* unknown conditionals are always fals
Being late to the review party here.
> +static int include_condition_is_true(const char *cond, size_t cond_len)
> +{
...
> +
> + error(_("unrecognized include condition: %.*s"), (int)cond_len, cond);
> + /* unknown conditionals are always false */
> + return 0;
> +}
Thanks for p
Jeff King writes:
> I don't think driving that with a two-entry table is the right thing
> here. We are as likely to add another "foobar:" entry as we are to add
> another modifier "/i" modifier to "gitdir:", and it is unclear whether
> that modifier would be mutually exclusive with "/i".
OK, I
On Fri, Feb 24, 2017 at 09:46:17AM -0800, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> >>> + if (skip_prefix_mem(cond, cond_len, "gitdir:", &cond, &cond_len))
> >>> + return include_by_gitdir(cond, cond_len, 0);
> >>> + else if (skip_prefix_mem(cond, cond_len, "gitdir/i:",
Duy Nguyen writes:
>>> + if (skip_prefix_mem(cond, cond_len, "gitdir:", &cond, &cond_len))
>>> + return include_by_gitdir(cond, cond_len, 0);
>>> + else if (skip_prefix_mem(cond, cond_len, "gitdir/i:", &cond,
>>> &cond_len))
>>> + return include_by_gitdir(cond, co
On Fri, Feb 24, 2017 at 2:59 AM, Junio C Hamano wrote:
> The variable is obviously not treated the same way as include.path ;-)
>
> When includeIf..path variable is set in a
> configuration file, the configuration file named by that
> variable is included (in a way similar to how inclu
Nguyễn Thái Ngọc Duy writes:
>> There was some discussion after v4. I think the open issues are:
>>
>> - the commit message is rather terse (it should describe motivation,
>> and can refer to the docs for the "how")
> This allows some more flexibility in managing configuration across
> re
This allows some more flexibility in managing configuration across
repositories. The most often seen use case on the mailing list is when
the user needs to use different email addresses on different
repositories. If these repositories share something that we can use to
group them up, then we can se
9 matches
Mail list logo
