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

[Junio C Hamano <gitster@pobox.com>]

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

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