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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 3, 2016, 21:56 UTC
Message-ID: <xmqqh98t5c69.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kYt+Z=ff1b2G+wWRAGGS=je+dpksfmMXj0fWwYVvHk8Cg@mail.gmail.com>

Stefan Beller <sbeller@google.com> 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.