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

[Elijah Newren <newren@gmail.com>]

On Mon, Dec 13, 2021 at 10:11 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "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?

Yeah, fair enough, I can change it to just print that it's already disabled.

However, I think add, list, and reapply should all die still.

> 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

You can get empty output from
   git sparse-checkout list

after running
   git sparse-checkout --cone

(cone mode, no paths specified)

In this state, only files immediately in the toplevel directory will
be present; all subdirectories will be sparsified away.

(Granted, that's because cone mode by default gives you some pattern
lists behind the scenes.  If you actually delete all entries in
.git/info/sparse-checkout and do a git sparse-checkout reapply, then
you will have NO (tracked) files in your checkout; everything will be
SKIP_WORKTREE.)

>  (B) sparse-checkout is not in effect at all.

In this state, the tree is dense; all files are present.

> If that is the case, please ignore all of the above.

I think your comment about disable makes sense, though.