Subject: Re: [PATCH v4 07/20] test-read-cache: print cache entries with --table

From: Derrick Stolee <[email-masked]>
Date: Tue, 30 Mar 2021 07:28:55 -0400

On 3/29/2021 5:44 PM, Junio C Hamano wrote:
> Derrick Stolee <[email-masked]> writes:
> 
>> I think changing 'ls-files' before the sparse index has stabilized is
>> premature. I said that a series like the RFC you sent would be
>> appropriate after this concept is more stable. I do _not_ recommend
>> trying to juggle it on top of the work while the patches are in flight.
> 
> I do not have a problem with either of approaches to help debugging
> (i.e. extending "ls-files --debug" or a new test helper), but I am
> curious to be reminded what the plan for "git ls-files [-s]" output
> is, when run in a repository in which sparse cone checkout is used.
> 
> Do we see trees and paths outside the cone omitted, or does the act
> of running "ls-files" dehydrate the trees into their constituent
> blobs?

At the moment, end-to-end behavior is identical as before: sparse
directory entries are expanded to all of the contained blobs instead
of writing the tree entries.

The sparse-index work will not be complete until every command is
audited for potential behavior change when disabling the
command_requires_full_index setting. That includes deciding what
is the best decision for ls-files, and will likely include an option
for both possible outputs (tree entries, or expanding to blobs). The
interesting discussion that is worth its own topic is whether or not
the tree entries should be displayed by default.

So the plan is: this _will_ be addressed, but in the future after
the core functionality and value of the sparse-index is set.

Thanks,
-Stolee