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

From: Stefan Beller <sbeller@google.com>
Date: Oct 3, 2016, 22:17 UTC
Message-ID: <CAGZ79kY+yB-AxRUt0rArGw6DaLDsMZDjKt2jQh9B=P-79T+qYQ@mail.gmail.com>
In-Reply-To: <xmqqh98t5c69.fsf@gitster.mtv.corp.google.com>

On Mon, Oct 3, 2016 at 2:56 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

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

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?

Show 7 quoted lines

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