On Mon, Dec 13, 2021 at 10:11 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > From: Elijah Newren <newren@xxxxxxxxx> > > > > 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@xxxxxxxxxxxxx> > > Reviewed-by: Victoria Dye <vdye@xxxxxxxxxx> > > Signed-off-by: Elijah Newren <newren@xxxxxxxxx> > > --- > > 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.
