Re: [PATCH 05/16] ls-files: add --narrow-checkout option to "will checkout" entries

[Junio C Hamano <gitster@pobox.com>]

Jakub Narebski <jnareb@gmail.com> writes:

>> @@ -72,6 +73,11 @@ OPTIONS
>>  	to file/directory conflicts for checkout-index to
>>  	succeed.
>>  
>> +--narrow-checkout::
>> +	When narrow checkout is being used, this option together with other
>> +	index-based selection options like --cached or --stage, only narrowed
>> +	portion will be printed out.
>> +
>
> I would rather say, that if git-ls-files is requested to show index
> content (by using selection options like --cached or --stage), then
> by default it shows all entries, also those marked "no checkout".
> With this option git-ls-files would show only files that would get
> checked out.

ls-files is a very low-level interrogator, and I have this queasy feeling
in the stomach if it suddenly stopped showing half of the index without
explicitly asked to with an option like this.  If somebody iterates over
ls-files output (with or without pathspecs), most often it would be to do
something interesting on the work tree files that correspond to these
paths, and for that use case it would make sense to have a mode that shows
only the paths marked for checkout.  But unless you can prove that "most
often" above is "100%", you risk breaking somebody's script.  Maybe you
are doing something similar [*1*] to the index-filter feature of
filter-branch, starting from the current index that has no-checkout marks
in its entries, and it wants to know all the paths in the index.  Who
knows?


[Footnote]

*1* filter-branch happens to start with an empty index and does not know
about the new 'narrow checkout' feature, so it is Ok, but it is plausible
as an optimization for it to prime the initial index from the current
"real" index, which may have the no-checkout marks.