Subject: Re: [PATCH v2 0/6] sparse checkout: fix a few bugs and check argument validity for set/add

From: Derrick Stolee <[email-masked]>
Date: Tue, 15 Feb 2022 10:15:01 -0500

On 2/15/2022 3:32 AM, Elijah Newren via GitGitGadget wrote:
> == Maintainer notes ==
> 
> Note1: This has been rebased on origin/master. v1 wasn't picked up anyway,
> so this shouldn't matter, but just pointing it out.
> 
> Note2: There is a small textual and small semantic conflict with
> ds/sparse-checkout-requires-per-worktree-config in seen. I included the diff
> with the correct resolution near the end of this cover letter.
> 
> == Overview ==
> 
> This series continues attempts to make sparse-checkouts more user friendly.
> A quick overview:
> 
>  * Patches 1-2 fix existing bugs from en/sparse-checkout-set (i.e. in
>    v2.35.0)
>  * Patch 3 fixes sparse-checkout-from-subdirectories-ignores-"prefix" (see
>    https://lore.kernel.org/git/[email-masked]/),
>    in cone mode. Since we'll get nasty surprises whether we use or don't use
>    "prefix" for non-cone mode, simply throw an error if set/add subcommands
>    of sparse-checkout are run from a subdirectory.
>  * Patches 4-6 check positional arguments to set/add and provide
>    errors/warnings for very likely mistakes. It also adds a --skip-checks
>    flag for overridding in case you have a very unusual situation.
> 
> == Update history ==
> 
> Changes since v1:
> 
>  * Dropped the commit changing cone-mode to default (patch 7, which will be
>    split into multiple patches and submitted as a separate series)
>  * Removed the RFC label
>  * Decided to error out when running set/add with paths from a subdirectory
>    in non-cone mode, and added tests
>  * Changed the warning for non-cone mode with individual files to point out
>    that the user is likely trying to select an individual file, but should
>    likely add a leading slash to ensure that is what happens
>  * Fixed typos, removed unnecessary condition checks

Thanks for these updates.

We already discussed the changes that are different from my recommendations,
and I agree with your new approach in those.

I read the range-diff carefully and found this version to resolve all of my
concerns with v1.

Reviewed-by: Derrick Stolee <[email-masked]>

Thanks,
-Stolee