Re: [PATCH v1 1/2] builtin/grep.c: add --sparse option

[Derrick Stolee <derrickstolee@github.com>]

On 8/17/2022 1:34 PM, Victoria Dye wrote:
> Junio C Hamano wrote:
>> Yup.  Is that "--sparse" or "--unsparse"?  We are busting the sparse
>> boundary and looking for everything, and calling the option to do so
>> "--sparse" somehow feels counter-intuitive, at least to me.
> 
> It is a bit unintuitive, but '--sparse' is already used to mean "operate on
> SKIP_WORKTREE entries (i.e., pretend the repo isn't a sparse-checkout)" in
> both 'add' (0299a69694 (add: implement the --sparse option, 2021-09-24)) and
> 'rm' (f9786f9b85 (rm: add --sparse option, 2021-09-24)). The
> 'checkout-index' option '--ignore-skip-worktree-bits' indicates similar
> behavior (and is, IMO, similarly confusing with its use of "ignore").
> 
> I'm not sure '--unsparse' would fit as an alternative, though, since 'git
> grep' isn't really "unsparsifying" the repo (to me, that would imply
> updating the index to remove the 'SKIP_WORKTREE' flag). Rather, it's looking
> at files that are sparse when, by default, it does not. 
> 
> I still like the consistency of '--sparse' with existing similar options in
> other commands but, if we want to try something clearer here, maybe
> something like '--search-sparse' is more descriptive?

My interpretation of '--sparse' is "include skip-worktree paths"
thinking of those paths being "sparse paths".

A too-long version could be '--ignore-sparse-checkout', but I can
understand the confusion where '--sparse' is interpreted as
'--respect-sparse-checkout'.

The existing pattern here means that it isn't Shaoxuan's responsibility
to pick a better name, but if we are interested in changing the name,
then we have some work to replace the previous '--sparse' options with
that name. I could do that replacement, assuming we land on a better name
and are willing to have that change of behavior.

Thanks,
-Stolee