On 3/29/2021 5:44 PM, Junio C Hamano wrote: > Derrick Stolee <stolee@xxxxxxxxx> 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
