Re: [PATCH v3 03/10] sparse-checkout: add sanity-checks on initial sparsity state

>
> "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Elijah Newren <newren@gmail.com>
> >
> > Most sparse-checkout subcommands (list, add, reapply, disable)
> > only make sense when already in a sparse state.  Add a quick check
> > that will error out early if this is not the case.
> >
> > Reviewed-by: Derrick Stolee <dstolee@microsoft.com>
> > Reviewed-by: Victoria Dye <vdye@github.com>
> > Signed-off-by: Elijah Newren <newren@gmail.com>
> > ---
> >  builtin/sparse-checkout.c          | 12 ++++++++++++
> >  t/t1091-sparse-checkout-builtin.sh | 10 +++++++++-
> >  2 files changed, 21 insertions(+), 1 deletion(-)
>
> I won't complain too much but some looks a bit questionable to die
> on.  For example, when asked to "please disable" something that is
> already disabled, I do not think the user's intention includes "if
> already disabled, please die"; rather it is "I want the end result
> to be in the disabled state", isn't it?

> I think what is common among the ones that I find questionable to
> die is that they do not use end-user input from argv.  "Please add X
> to sparsity patterns" may not make much sense when we are not already
> sparse", unlike "Please disable", for example.
>
>     Side note. I suspect that it can be argued that we might just
>     auto-enable sparse state upon the first request to add
>     something, but I personally feel that is dwimming too much, as
>     behaviours of git in normal mode and sparse mode are so
>     different.
>
> So, for the same reason, I think "list" that shows "there is
> nothing" without an error, when sparse-checkout is not active, would
> also be perfectly defensible, and some people may find that dying a
> bit too much in such a situation.
>
> Or does the system work differently between
>
>  (A) core_apply_sparse_checkout is true and the sparsity pattern list is
>      empty, and