Re: [WIP v1 3/4] mv: add advise_to_reapply hint for moving file into cone

[Derrick Stolee <derrickstolee@github.com>]

On 3/31/2022 5:17 AM, Shaoxuan Yuan wrote:
> Originally, the SKIP_WORKTREE bit is not removed when moving an out-of-cone
> file into sparse cone, thus the moved file does not show up in the working tree.
> Hint the user to use "git sparse-checkout reapply" to reapply the sparsity rules
> to the working tree, by which the SKIP_WORKTREE bit is removed.
> 
> Signed-off-by: Shaoxuan Yuan <shaoxuan.yuan02@gmail.com>
> ---
> I offered this solution becasue I'm not sure how to turn a cache_entry's 
> ce_flags back to a non-sparse state. I tried directly set it to 0 like this:
> 
> 	ce->ce_flags = 0;
> 
> But the behavior after this seems undefined. The file still won't show up
> in the working tree.
> 
> And I found that "git sparse-checkout reapply" seems to be a nice fit for the
> job. But I guess if there is a way (there must be but I don't know) to do it
> direcly in the code, that could also be nice.

I point out lower down the API that the 'reapply' command uses to gain
this functionality.

>  	if (gitmodules_modified)
> @@ -392,6 +398,9 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
>  			       COMMIT_LOCK | SKIP_IF_UNCHANGED))
>  		die(_("Unable to write new index file"));
>  
> +	if (advise_to_reapply)
> +		printf(_("Please use \"git sparse-checkout reapply\" to reapply the sparsity.\n"));
> +

I think we can skip the advice here and instead run update_sparsity()
from unpack-trees.c (see update_working_directory() in builtin/sparse-checkout.c
for an example using it). Something along those lines would double-check the
new cache entries against the sparse-checkout patterns and update the worktree
to match expectation.

I originally thought we wouldn't want to run update_sparsity() unless we
interacted with a cache entry with SKIP_WORKTREE, but this could be important
for moving things from inside the cone to outside. In addition, in non-cone
mode there is no way to predict how the new cache entry could match the
patterns once its name changes.

Hopefully this gives you something to try, especially because it should be
simple to check that a file exists or not after the 'git mv' call, making
testing relatively easy.

Thanks,
-Stolee