Re: [PATCH v2 5/6] Comment important codepaths regarding nuking untracked files/dirs

On Fri, Sep 24, 2021 at 10:50 AM Eric Sunshine [off-list ref] wrote:

On Fri, Sep 24, 2021 at 2:37 AM Elijah Newren via GitGitGadget
[off-list ref] wrote:

quoted

In the last few commits we focused on code in unpack-trees.c that
mistakenly removed untracked files or directories.  There may be more of
those, but in this commit we change our focus: callers of toplevel
commands that are expected to remove untracked files or directories.

As noted previously, we have toplevel commands that are expected to
delete untracked files such as 'read-tree --reset', 'reset --hard', and
'checkout --force'.  However, that does not mean that other highlevel
commands that happen to call these other commands thought about or
conveyed to users the possibility that untracked files could be removed.
Audit the code for such callsites, and add comments near existing
callsites to mention whether these are safe or not.
[...]
Signed-off-by: Elijah Newren <redacted>
---

diff --git a/builtin/worktree.c b/builtin/worktree.c

@@ -356,6 +356,11 @@ static int add_worktree(const char *path, const char *refname,
+               /*
+                * NOTE: reset --hard is okay here, because 'worktree add'
+                * refuses to work in an extant non-empty directory, so there
+                * is no risk of deleting untracked files.
+                */
                strvec_pushl(&cp.args, "reset", "--hard", "--no-recurse-submodules", NULL);

I understand that this comment helps you or some other person auditing
similar cases in the future, however, as a standalone comment for a
reader who isn't aware of the intention, it seems more confusing than
illuminating. It also detracts from the important purpose of `--hard`
here, which is that it is necessary in order to get `git reset` to
actually "checkout" the files into the empty directory, so use of
`--hard` is not an accident or carelessness.

Fair enough; I'll strike it.

These days, we'd probably just use:

    git restore --no-recurse-submodules .

instead (including the final `.`) to achieve the same, and that
wouldn't need any sort of cuationary comment like the one being added
by this patch. So, perhaps that's a better way to go, or maybe it's
outside the scope of this series...

Yeah, that'd make sense.  Though it'd make even more sense to get rid
of the subprocess forking.  Definitely something for a different
series, though.