On Mon, Oct 3, 2016 at 2:56 PM, Junio C Hamano <[email protected]> wrote:
> Stefan Beller <[email protected]> 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.
So how would we go about git_all_attrs then?
I think those (only builtin/check-attr.c as well as Documentation) would
need to read these names off of git_attr_check_elem.
So instead we could do a
int git_all_attrs(const char *path, char *result_keys[], char *result_values[],
int nr, int alloc)
Internally git_all_attrs would use nr/alloc to resize result_{key,value} to an
appropriate size and then fill it with keys/values.
Although I do not think check-attr needs to be fast as it is a debugging
tool rather than a daily used tool, but it would fit into the current
line of thinking?
>
> 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 don't think we have the same idea how it should look like, as e.g.
it is unclear what we do with the `const struct git_attr` in the
git_attr_check to me.
> 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.
Ok, so let's first define how the future proofed API should look like
and then we can go towards it.
