On Mon, Dec 13, 2021 at 10:23 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> "Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
> > From: Elijah Newren <newren@xxxxxxxxx>
> >
> > Folks may want to switch to or from cone mode, or to or from a
> > sparse-index without changing their sparsity paths. Allow them to do so
> > using the reapply command.
>
> Interesting.
>
> Are there certain pattern that would make sense only in one of the
> modes but not the other? If there isn't any such pattern, this
> feature perfectly makes sense, I would think.
Good question.
Valid cone mode patterns are a strict subset of the possible sparsity
patterns. So, switching from cone to non-cone mode trivially makes
sense. Understanding why switching in the other direction is okay
takes a bit more understanding...
Stolee designed cone mode such that when it's active, and someone
edits .git/info/sparse-checkout and adds patterns of their own (which
users might do because that had been suggested for several years in
the read-tree docs -- and still is), then the code will print a
warning ("disabling cone pattern matching") and operate in non-cone
mode. As such, the sparsity does not "break" when they switch modes
if they have non-cone patterns; they'll just get warnings.
Further, we're making `reapply` consistent with `init` here. Stolee
made `init` usable for switching modes in an active sparse-checkout
(though it wasn't well documented, and it's slightly confusing to
users who might worry that they'll lose their sparsity patterns by
using `init`). We're just copying that ability from `init` over in
`reapply`, and recommending using the latter rather than the former.
> If an existing pattern changes its meaning between the old mode and
> the new mode, that is very much fine---that is what the user wanted
> to achieve by switching between the modes with "reapply".
>
> Thanks.
