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

2 messages, 2 authors, 2021-03-30 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2021-03-29 21:45:06

Derrick Stolee [off-list ref] 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?

Thanks.

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

From: Derrick Stolee <hidden>
Date: 2021-03-30 11:29:54

On 3/29/2021 5:44 PM, Junio C Hamano wrote:
Derrick Stolee [off-list ref] writes:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help