Add a "remove" subcommand to "git-sparse-checkout"

Add a "remove" subcommand to "git-sparse-checkout"

[Shaoxuan Yuan]

Hi all,

I'm wondering do we have a plan to add a "remove" subcommand
to the existing "git-sparse-checkout" command set?

Because when I am messing with sparse-checkout, I sometimes want
to remove a directory from cone, and I have to either go into
".git/info/sparse-checkout"
to manually remove it, or "disable" then "init" or "set" the
directories all over again.

I think it will be nice to "remove" a directory, then "reapply" to get
the job done.

-- 
Thanks & Regards,
Shaoxuan

Re: Add a "remove" subcommand to "git-sparse-checkout"

[Derrick Stolee]

On 3/27/2022 11:46 PM, Shaoxuan Yuan wrote:
> Hi all,
> 
> I'm wondering do we have a plan to add a "remove" subcommand
> to the existing "git-sparse-checkout" command set?
> 
> Because when I am messing with sparse-checkout, I sometimes want
> to remove a directory from cone, and I have to either go into
> ".git/info/sparse-checkout"
> to manually remove it, or "disable" then "init" or "set" the
> directories all over again.
> 
> I think it will be nice to "remove" a directory, then "reapply" to get
> the job done.
 
This is definitely something that can be done. I didn't include
it in the original plan (it is a natural analogue to 'add') because
of strange UX issues that arise when thinking about it a little
while.

Imagine this sequence of events:

	git sparse-checkout set A/B/C D/E
	git sparse-checkout add A/B
	git sparse-checkout remove A/B

In this sequence, A/B/C was declared as an important directory,
but then it gets removed from the sparse-checkout file because
it becomes implies by A/B.

When removing A/B, the most obvious implementation would remove
everything under A/B. But, would a user expect to have Git
remember A/B/C?

This is just a subtle point that has prevented me from building
the feature proactively. If someone else has a deeper need for
the feature, then choosing what works best for their expectations
(with enough documentation to assist anyone with a different
expectation) would be sufficient.

Also, if you implement a 'git sparse-checkout remove', then I
do not anticipate a 'reapply' being necessary afterwards. It
should update the worktree before exiting.

Thanks,
-Stolee