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

From: Derrick Stolee <derrickstolee@github.com>
Date: Mar 28, 2022, 13:11 UTC
Message-ID: <41050612-b5ba-c394-a288-000d5a49e51a@github.com>
In-Reply-To: <CAJyCBORyNQX7u5=ZTdyHWyb63r-Cus4hb_yZingm4B=J4pjhkA@mail.gmail.com>

On 3/27/2022 11:46 PM, Shaoxuan Yuan wrote:

Show 13 quoted lines

> 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