Re: [PATCH 05/16] ls-files: add --narrow-checkout option to "will checkout" entries
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 15, 2008, 20:20 UTC
- Message-ID
- <7v3ak1b1q7.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <m34p4io8vt.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
Show 15 quoted lines
>> @@ -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.