Re: [WIP v2 2/5] mv: check if out-of-cone file exists in index with SKIP_WORKTREE bit
- From
Shaoxuan Yuan <shaoxuan.yuan02@gmail.com>
- Date
- May 31, 2022, 08:06 UTC
- Message-ID
- <CAJyCBORP74=nC1cB5r41MqS+WD-JfNX+8AOv7jqevN9FZGWdSw@mail.gmail.com>
- In-Reply-To
- <0884b97b-0745-5cad-3034-a679be5d6c3a@github.com>
On Fri, May 27, 2022 at 11:13 PM Derrick Stolee <derrickstolee@github.com> wrote:
Show 23 quoted lines
> > diff --git a/builtin/mv.c b/builtin/mv.c
> > index 83a465ba83..32ad4d5682 100644
> > --- a/builtin/mv.c
> > +++ b/builtin/mv.c
> > @@ -185,8 +185,32 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
> >
> > length = strlen(src);
> > if (lstat(src, &st) < 0) {
> > + /*
> > + * TODO: for now, when you try to overwrite a <destination>
> > + * with your <source> as a sparse file, if you supply a "--sparse"
> > + * flag, then the action will be done without providing "--force"
> > + * and no warning.
> > + *
> > + * This is mainly because the sparse <source>
> > + * is not on-disk, and this if-else chain will be cut off early in
> > + * this check, thus the "--force" check is ignored. Need fix.
> > + */
>
> I wonder if this is worth the comment here, or if we'd rather see
> the mention in the commit message. You have documented tests that
> fail in this case, so we already have something that marks this
> as "TODO" in a more discoverable place.This comment was added during my local development, it should be removed.
Show 48 quoted lines
> > + int pos = cache_name_pos(src, length);
> > + if (pos >= 0) {
> > + const struct cache_entry *ce = active_cache[pos];
> > +
> > + if (ce_skip_worktree(ce)) {
> > + if (!ignore_sparse)
> > + string_list_append(&only_match_skip_worktree, src);
> > + else
> > + modes[i] = SPARSE;
>
>
> > + }
> > + else
> > + bad = _("bad source");
>
> style nit:
>
> } else {
> bad = _("bad source");
> }
>
> > + }
> > /* only error if existence is expected. */
> > - if (modes[i] != SPARSE)
> > + else if (modes[i] != SPARSE)
> > bad = _("bad source");
>
> For this one, the comment makes it difficult to connect the 'else
> if' to its corresponding 'if'. Perhaps:
>
> } else if (modes[i] != SPARSE) {
> /* only error if existence is expected. */
> bad = _("bad source");
> }
>
> > } else if (!strncmp(src, dst, length) &&
> > (dst[length] == 0 || dst[length] == '/')) {
>
> In general, I found this if/else-if chain hard to grok, and
> a lot of it is because we have "simple" cases at the end
> and the complicated parts have ever-increasing nesting. This
> is mostly due to the existing if/else-if chain in this method.
>
> Here is a diff that replaces that if/else-if chain with a
> 'goto' trick to jump ahead, allowing some code to decrease in
> tabbing:
>
> ---- >8 ----[cutting the proposed refactor for space]
Show 49 quoted lines
> ---- >8 ----
>
> But mostly the reason for this refactor is that the following
> diff should be equivalent to yours:
>
> ---- >8 ----
>
> diff --git a/builtin/mv.c b/builtin/mv.c
> index d8b5c24fb5..add48e23b4 100644
> --- a/builtin/mv.c
> +++ b/builtin/mv.c
> @@ -185,11 +185,28 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
>
> length = strlen(src);
> if (lstat(src, &st) < 0) {
> - /* only error if existence is expected. */
> - if (modes[i] != SPARSE) {
> + int pos;
> + const struct cache_entry *ce;
> +
> + pos = cache_name_pos(src, length);
> + if (pos < 0) {
> + /* only error if existence is expected. */
> + if (modes[i] != SPARSE)
> + bad = _("bad source");
> + goto act_on_entry;
> + }
> +
> + ce = active_cache[pos];
> + if (!ce_skip_worktree(ce)) {
> bad = _("bad source");
> goto act_on_entry;
> }
> +
> + if (!ignore_sparse)
> + string_list_append(&only_match_skip_worktree, src);
> + else
> + modes[i] = SPARSE;
> + goto act_on_entry;
> }
> if (!strncmp(src, dst, length) &&
> (dst[length] == 0 || dst[length] == '/')) {
> ---- >8 ---
>
> To me, this is a bit easier to parse, since we find the error
> cases and jump to the action before continuing on the "happy
> path". It does involve that first big refactor first, so I'd
> like to hear opinions of other contributors before you jump to
> taking this suggestion.True. I also find it easier to read. Though Victoria mentioned the goto hazard, the gotos here decouples the huge chain and that brings clarity and makes it easier to extend.
-- Thanks & Regards, Shaoxuan