Re: Re attr API further revamp

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 13, 2016, 21:54 UTC
Message-ID: <xmqqk2hsbvpr.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kYy4ic1nYgPEHLCfoUZYkzPw3bBq+8kTyRi13nNwQHGFw@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 5 quoted lines

> On Mon, Jun 13, 2016 at 1:55 PM, Junio C Hamano <gitster@pobox.com> 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...

Show 7 quoted lines

>>         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.