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

From: Derrick Stolee <stolee@gmail.com>
Date: Mar 17, 2021, 19:46 UTC
Message-ID: <d93300ad-9a3b-6de4-c497-acd56eff30dc@gmail.com>
In-Reply-To: <CABPp-BGS7BxbxiPvk7zoO1XdbZSkpyrfYLuyiNnR+d6orPn+rw@mail.gmail.com>

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>

Show 15 quoted lines

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

Thanks, -Stolee