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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 17, 2022, 18:47 UTC
Message-ID: <xmqqlermwvus.fsf@gitster.g>
In-Reply-To: <e719d1e1-1849-07bc-ea08-2729985e5048@github.com>

Derrick Stolee <derrickstolee@github.com> writes:

Show 6 quoted lines

>> 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").

OK, I forgot about these precedents. "ignore skip worktree bits" is quite a mouthful, but expresses what is going on quite clearly. Instead of honoring the skip-worktree bit, behave as if they are not set, so we bust the "sparse" boundary.

Show 5 quoted lines

> 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.

It all depends on how deeply the existing "--sparse" are anchored in users' minds. If we have been with them for nearly a year and three major releases, it is too late to casually "fix" without a proper transition strategy, I am afraid. And I am not even sure if it is worth the trouble.

In any case, let's leave it totally outside the scope of the topic. As long as we are consistently unintuitive with "--sparse", then I think we are OK, because users are malleable and can easily get used to anything as long as it is consistent ;-)

Thanks.