Re: [RFC/PATCH 0/5] Re: [PATCH v3 07/20] test-read-cache: print cache entries with --table

> On Wed, Mar 17, 2021 at 12:46 PM Derrick Stolee <stolee@gmail.com> wrote:
>>
>> On 3/17/2021 2:28 PM, Elijah Newren wrote:
>>> On Wed, Mar 17, 2021 at 6:28 AM Ævar Arnfjörð Bjarmason
>>> <avarab@gmail.com> wrote:
>>>>
>>>>> From: Derrick Stolee <dstolee@microsoft.com>
>>
>>>>
>>>> So we have a test tool that's mostly ls-files but mocks the output
>>>> ls-tree would emit, won't these tests eventually care about what stage
>>>> things are in?
>>>>
>>>> What follows is an RFC series on top that's the result of me wondering
>>>> why if we're adding new index constructs we aren't updating our
>>>> plumbing to emit that data, can we just add this to ls-files and drop
>>>> this test helper?
>>>>
>>>> Turns out: Yes we can.
>>>
>>> I like the idea of having ls-files be usable to show the entries that
>>> are in the index; that seems great to me.  I very much dislike the
>>> --sparse flag to ls-files, as noted on that commit.
>>
>> I don't like this idea. I don't think exposing internal structures
>> like this is something we want to do so quickly.
> 
> Not sure I follow; ls-files was already about exposing three bits of
> internal structures for index entries: mode, hash, and stage number.
> These are quantities that are well-defined for sparse directories too.
> It would not be exposing any new or different internal structures, nor
> changing the output format.  (Ævar changed the tests to not look for
> "tree" but to look for the "040000" mode number.)

>>  Further, I intend
>> to use this test tool in the future to _also_ show the stored stat()
>> data, which would be inappropriate here in ls-files.
>>
>> I would prefer to continue using the test helper here and leave
>> functional changes to ls-files be considered independently.
> 
> Well, I was okay with it being in a test helper regardless of whether
> it could be done with ls-files, and then just circling back and fixing
> up ls-files later.  But perhaps it's worth calling out in the commit
> message about your plans to add stat() data and how that future piece
> can't be done in ls-files (without functional changes of some sort)
> just to make it clearer why we're using a test helper instead of
> front-loading the port of ls-files over to sparse-indexes?