Subject: Re: What's cooking in git.git (Sep 2016, #08; Tue, 27)

From: Junio C Hamano <[email-masked]>
Date: Mon, 03 Oct 2016 14:56:46 -0700

Stefan Beller <[email-masked]> writes:

>     // Note: git_attr_check_elem seems to be useless now, as the
>     // results are not stored in there, we only make use of the `attr` key.

I do not think git_attr_check_elem would be visible to the callers,
once we split the "inquiry" and "result" like the code illustrated
above.  I actually doubt that the type would even internally need to
survive such a rewrite.

The point of "future-proofing" the callers is to hide such
implementation details from them.  We know that the current API will
need to be updated at least once to prepare the implementation of
the API so that it has some chance of becoming thread-safe, and I
think we know enough how the updated API should look like to the
callers.  I was hoping the minimum future-proofing would allow us to
update the current "attr" API users only once, without having to
update them again when we make it ready to be used in threaded
environment.