Subject: Re: Re attr API further revamp

From: Junio C Hamano <[email-masked]>
Date: Mon, 13 Jun 2016 14:54:56 -0700

Stefan Beller <[email-masked]> writes:

> On Mon, Jun 13, 2016 at 1:55 PM, Junio C Hamano <[email-masked]> wrote:
>> I hate to be doing this, but we need yet another revamp to the attr
>> API that affects all the callers.
>
> So you don't mean origin/jc/attr-more by this?

Not really; the tip of attr-more needs to be discarded after this
realization, but otherwise there is no API revamping in what is
queued on that topic.

> (Given that we have jc/attr and jc/attr-more, the third thing could go
> with jc/even-more-attr. Though I do not propose that)

The latter was merely because I couldn't rewind and rebuild the
former during the pre-release freeze.  The fixup! in the latter will
be squashed into the former, etc...

>>         static struct git_attr_check *ccheck;
>>         const char *values[NUM_ATTRS];
>>
>>         git_attr_check_initl(&ccheck, "crlf", "ident", ..., NULL);
>>         git_attr_check(path, ccheck, values);
>
> and later on each thread will do a

This will have to do nothing; it is "static", and will be held to
the end of the lifetime of the program.

You _can_ allocate the check structure per thread and free them when
thread exits, but the usage pattern that appear in convert.c is
oblivious to the threading.