Re: [PATCH 0/5] avoid peeking into `struct lock_file`

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 6, 2021, 22:36 UTC
Message-ID: <xmqqim89pu9k.fsf@gitster.c.googlers.com>
In-Reply-To: <xmqq5z4as2j9.fsf@gitster.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 21 quoted lines

> Derrick Stolee <stolee@gmail.com> writes:
>
>> On 1/5/2021 2:23 PM, Martin Ågren wrote:
>>> I made a comment in [1] about how we could avoid peeking into a `struct
>>> lock_file` and instead use a helper function that we happen to have at
>>> our disposal. I then grepped around a bit and found that we're pretty
>>> good at avoiding such peeking at the moment, but that we could do
>>> a bit better.
>>> 
>>> Here's a series to avoid such `lk.tempfile.foo` in favor of
>>> `get_lock_file_foo(&lk)`.
>>> 
>>> [1] https://lore.kernel.org/git/CAN0heSrOKr--GenbowHP+iwkijbg5pCeJLq+wz6NXCXTsfcvGg@mail.gmail.com/
>>
>> Thanks for being diligent and keeping the code clean.
>>
>> This series is good-to-go.
>>
>> Reviewed-by: Derrick Stolee <dstolee@microsoft.com>
>
> Thanks, both.

I liked what I saw. The code after these patches got certainly clearer.

But it was not quite clear what I was *NOT* seeing in these patches.

IOW, how extensive is the coverage of these patches? If we renamed the .tempfile field to, say, .tmpfile in "struct lock_file" in "lockfile.h", for example, would "lockfile.[ch]" be the *only* files that need to be adjusted to make the code compile again? The same question for various fields in "struct tempfile".