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

From: Victoria Dye <vdye@github.com>
Date: Mar 31, 2022, 21:56 UTC
Message-ID: <c483c964-3e99-4f43-3739-ca6de6670182@github.com>
In-Reply-To: <20220331091755.385961-4-shaoxuan.yuan02@gmail.com>

Shaoxuan Yuan wrote:

Show 15 quoted lines

> 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.
>

What (I think) you're looking for is something like this:

	ce->ce_flags &= ~CE_SKIP_WORKTREE;

This disables only the SKIP_WORKTREE flag on the entry (leaving the others unchanged). Similarly, you can enable SKIP_WORKTREE with:

	ce->ce_flags |= CE_SKIP_WORKTREE;

> 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.
>

This brings up an interesting point - what *do* we want to do when you move an entry and, based on sparse checkout patterns, the SKIP_WORKTREE status changes? In the case of sparse-checkout, I like your approach: disable SKIP_WORKTREE if you're moving inside the sparse checkout definition. And, this only happens if you're using the '--sparse' flag, so a user will have to acknowledge that they're moving something sparse to do any of this.

The other situation to consider is when you're moving something *out* of the sparse cone; your approach right now is to move it out *without* enabling SKIP_WORKTREE. I think this is also probably valid - you might not want to assume a user wants to remove the file from their worktree *just* yet. However, it does create a situation where a user has a "sparse" file active in their repo, so *this* might be a situation where you want to advise the user to call 'git sparse-checkout reapply' to "sparsify" that file.

In any case, you'll only want to do this if the global variable 'core_apply_sparse_checkout' is non-zero. 'SKIP_WORKTREE' can be used when not in a sparse checkout, so you can't always change the flag based on any sparse patterns (because there might not be any!).

Show 33 quoted lines

>  builtin/mv.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/builtin/mv.c b/builtin/mv.c
> index 9da9205e01..5f511fb8da 100644
> --- a/builtin/mv.c
> +++ b/builtin/mv.c
> @@ -138,6 +138,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
>  {
>  	int i, flags, gitmodules_modified = 0;
>  	int verbose = 0, show_only = 0, force = 0, ignore_errors = 0, ignore_sparse = 0;
> +	int advise_to_reapply = 0;
>  	struct option builtin_mv_options[] = {
>  		OPT__VERBOSE(&verbose, N_("be verbose")),
>  		OPT__DRY_RUN(&show_only, N_("dry run")),
> @@ -383,6 +384,11 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
>  		pos = cache_name_pos(src, strlen(src));
>  		assert(pos >= 0);
>  		rename_cache_entry_at(pos, dst);
> +		if (!advise_to_reapply &&
> +			!path_in_sparse_checkout(src, &the_index) &&
> +			path_in_sparse_checkout(dst, &the_index)) {
> +				advise_to_reapply = 1;
> +			}
>  	}
>  
>  	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 know you're hoping to change your implementation so that you don't need this advice. But, if you *do* end up needing it (or some other advice) somewhere else, you can implement it using the 'advise()' API. For an example on how that's used, see how 'ADVICE_SKIPPED_CHERRY_PICKS' is used in 'sequencer.c'.

In your case, you could have something like 'ADVICE_REAPPLY_SPARSE_PATTERNS' that, if enabled, prints a message like the one you have here.

> +
>  	string_list_clear(&src_for_dst, 0);
>  	UNLEAK(source);
>  	UNLEAK(dest_path);

As with patch 1, it would help paint a clear picture of what this patch does if you could incorporate the tests from patch 4 into this one.