Re: [PATCH v3 11/12] wt-status: expand added sparse directory entries
- From
Elijah Newren <newren@gmail.com>
- Date
- May 18, 2021, 02:27 UTC
- Message-ID
- <CABPp-BGww6VPMmp9dDyRJ2vgNCOdj16-LjU3aM3MM1NQ+T-pmg@mail.gmail.com>
- In-Reply-To
- <3b42783d4a86473420480b2789d61d8103e6e7d4.1621017072.git.gitgitgadget@gmail.com>
On Fri, May 14, 2021 at 11:31 AM Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com> wrote:
Show 5 quoted lines
> > From: Derrick Stolee <dstolee@microsoft.com> > > It is difficult, but possible, to get into a state where we intend to > add a directory that is outside of the sparse-checkout definition. Add a
Then we need to fix that; allowing things to be added outside the sparse-checkout definition is a bug[1][2]. That's an invariant I believe we should maintain everywhere; things get really confusing to users somewhere later down the road if we don't. Matheus worked to fix that with 'git add'; if there are other commands that need fixing too, then we should also fix them.
[1] https://lore.kernel.org/git/CABPp-BFhyFiKSXdLM5q5t=ZKzr6V0pY7dbheierRaOHFbMEdkg@mail.gmail.com/ [2] https://lore.kernel.org/git/CABPp-BF0ZhbSs42R3Bw_r-hbhQ71qtbXSBqXdq0djyaan=8p=A@mail.gmail.com/
> test to t1092-sparse-checkout-compatibility.sh that demonstrates this > using a combination of 'git reset --mixed' and 'git checkout --orphan'.
I think `git checkout --orphan` should just throw an error if sparse-checkout is in use. Allowing adding paths outside the sparse-checkout set causes too much collateral and deferred confusion for users.
Show 13 quoted lines
> This test failed before because the output of 'git status > --porcelain=v2' would not match on the lines for folder1/: > > * The sparse-checkout repo (with a full index) would output each path > name that is intended to be added. > > * The sparse-index repo would only output that "folder1/" is staged for > addition. > > The status should report the full list of files to be added, and so this > sparse-directory entry should be expanded to a full list when reaching > it inside the wt_status_collect_changes_initial() method. Use > read_tree_at() to assist.
Having a sparse directory entry whose object_id in the index does not match HEAD should be an error. Have a CE_SKIP_WORKTREE non-directory whose object_id in the index does not match HEAD should also be an error. I don't think we should complicate the code to try to handle violations of those assumptions. I do think we should add checks to enforce that constraint (or BUG() if it's violated).
And yeah, that also means 'git sparse-checkout add/set' would need to error out if paths are requested to be sparsified despite being different from HEAD.
Show 116 quoted lines
> Somehow, this loop over the cache entries was not guarded by
> ensure_full_index() as intended.
>
> Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
> ---
> t/t1092-sparse-checkout-compatibility.sh | 28 +++++++++++++
> wt-status.c | 50 ++++++++++++++++++++++++
> 2 files changed, 78 insertions(+)
>
> diff --git a/t/t1092-sparse-checkout-compatibility.sh b/t/t1092-sparse-checkout-compatibility.sh
> index 59faf7381093..cd3669d36b53 100755
> --- a/t/t1092-sparse-checkout-compatibility.sh
> +++ b/t/t1092-sparse-checkout-compatibility.sh
> @@ -492,4 +492,32 @@ test_expect_success 'sparse-index is not expanded' '
> test_region ! index ensure_full_index trace2.txt
> '
>
> +test_expect_success 'reset mixed and checkout orphan' '
> + init_repos &&
> +
> + test_all_match git checkout rename-out-to-in &&
> + test_all_match git reset --mixed HEAD~1 &&
> + test_sparse_match test-tool read-cache --table --expand &&
> + test_all_match git status --porcelain=v2 &&
> + test_all_match git status --porcelain=v2 &&
> +
> + # At this point, sparse-checkouts behave differently
> + # from the full-checkout.
> + test_sparse_match git checkout --orphan new-branch &&
> + test_sparse_match test-tool read-cache --table --expand &&
> + test_sparse_match git status --porcelain=v2 &&
> + test_sparse_match git status --porcelain=v2
> +'
> +
> +test_expect_success 'add everything with deep new file' '
> + init_repos &&
> +
> + run_on_sparse git sparse-checkout set deep/deeper1/deepest &&
> +
> + run_on_all touch deep/deeper1/x &&
> + test_all_match git add . &&
> + test_all_match git status --porcelain=v2 &&
> + test_all_match git status --porcelain=v2
> +'
> +
> test_done
> diff --git a/wt-status.c b/wt-status.c
> index 0425169c1895..90db8bd659fa 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -654,6 +654,34 @@ static void wt_status_collect_changes_index(struct wt_status *s)
> run_diff_index(&rev, 1);
> }
>
> +static int add_file_to_list(const struct object_id *oid,
> + struct strbuf *base, const char *path,
> + unsigned int mode, void *context)
> +{
> + struct string_list_item *it;
> + struct wt_status_change_data *d;
> + struct wt_status *s = context;
> + char *full_name;
> +
> + if (S_ISDIR(mode))
> + return READ_TREE_RECURSIVE;
> +
> + full_name = xstrfmt("%s%s", base->buf, path);
> + it = string_list_insert(&s->change, full_name);
> + d = it->util;
> + if (!d) {
> + CALLOC_ARRAY(d, 1);
> + it->util = d;
> + }
> +
> + d->index_status = DIFF_STATUS_ADDED;
> + /* Leave {mode,oid}_head zero for adds. */
> + d->mode_index = mode;
> + oidcpy(&d->oid_index, oid);
> + s->committable = 1;
> + return 0;
> +}
> +
> static void wt_status_collect_changes_initial(struct wt_status *s)
> {
> struct index_state *istate = s->repo->index;
> @@ -668,6 +696,28 @@ static void wt_status_collect_changes_initial(struct wt_status *s)
> continue;
> if (ce_intent_to_add(ce))
> continue;
> + if (S_ISSPARSEDIR(ce->ce_mode)) {
> + /*
> + * This is a sparse directory entry, so we want to collect all
> + * of the added files within the tree. This requires recursively
> + * expanding the trees to find the elements that are new in this
> + * tree and marking them with DIFF_STATUS_ADDED.
> + */
> + struct strbuf base = STRBUF_INIT;
> + struct pathspec ps;
> + struct tree *tree = lookup_tree(istate->repo, &ce->oid);
> +
> + memset(&ps, 0, sizeof(ps));
> + ps.recursive = 1;
> + ps.has_wildcard = 1;
> + ps.max_depth = -1;
> +
> + strbuf_add(&base, ce->name, ce->ce_namelen);
> + read_tree_at(istate->repo, tree, &base, &ps,
> + add_file_to_list, s);
> + continue;
> + }
> +
> it = string_list_insert(&s->change, ce->name);
> d = it->util;
> if (!d) {
> --
> gitgitgadgetThis was a really nice catch that you got this particular testcase. While I disagree with the fix, I do have to say nice work on the catch and the implementation otherwise.