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@xxxxxxxxx>
> ---
> 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!).
> 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.
