Nguyễn Thái Ngọc Duy wrote:
> Sparse checkout updates worktree based on the old and new
> skip-worktree status when $GIT_DIR/info/sparse-checkout changes:
>
> old = ce_skip_worktree(ce); // current skip-worktree
> new = will_have_skip_work_tree(ce); // from $GIT..sparse-checkout
> if (old && !new) add_file_back(ce); // shrink checkout area
> if (!old && new) remove_file_out(ce); [1] // enlarge checkout area
>
> New entries after merging will always have skip-worktree unset
> (i.e. old = 0). If those files are filtered out by
> $GIT_DIR/info/sparse-checkout (i.e. new != 0), then case [1] will
> happen. But there is nothing to remove because they're new.
When using unpack_trees to add a new file, there is no in-file
index entry to grab the previous skip worktree bit from. If it
is outside the checkout area, we should pretend it was skipped before,
too; otherwise a checkout can cause a file on disk whose name
coincides with a newly added outside-worktree file to be deleted.
Do I understand correctly?
> +++ b/unpack-trees.c
> @@ -1091,6 +1091,8 @@ static int merged_entry(struct cache_entry *merge, struct cache_entry *old,
> if (!old) {
> if (verify_absent(merge, "overwritten", o))
> return -1;
> + if (!o->skip_sparse_checkout && will_have_skip_worktree(merge, o))
> + update |= CE_SKIP_WORKTREE;
> invalidate_ce_path(merge, o);
> } else if (!(old->ce_flags & CE_CONFLICTED)) {
> /*
Looks sane.
Thanks for the fixes,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html