Re: [PATCH] stash: disable literal treatment when passing top pathspec

[Junio C Hamano <gitster@pobox.com>]

Kyle Meyer <kyle@kyleam.com> writes:

> However, for --include-untracked/clean case, the subprocess directory is
> set to startup_info->original_cwd since 0fce211ccc (stash: do not
> attempt to remove startup_info->original_cwd, 2021-12-09).

Interesting.  I find the logic there a bit convoluted.  IIUC, it
goes like this:

 - we do not want to lose the directory our process was originally
   in, which is recorded in startup_info->original_cmd.

 - we have gone up to the root of the working tree, and running
   "clean" from there is what we want---even if we started "git
   stash" from a subdirectory, we want to make the entire working
   tree clean, not just inside our subdirectory.

 - but we came up with a hack that allows us to skip removing the
   directory the Git process started at.  To take advantage of the
   mechanism, we'd need to start from that original_cmd.

 - but then "clean" run from that subdirectory normally cleans only
   that subdirectory, which is not what we want to do.  To work it
   around, we'd need to pass :/ pathspec to say that we are cleaning
   from the top.

It makes me suspect that "we protect current directory" is a too
specialized way that didn't really consider the possibility that we
sometimes spawn a subcommand.  Even "we protect this directory" may
not be sufficient and we may need a "we protect these directories",
I suspect.  When the user originally starts "git foo" in one
directory, which may have to run "git bar" in another directory, and
"git bar" would want to protect the directory it starts in and also
where "git foo" started from, no?  It almost makes me suspect that
we'd want some "git" wide option that allows us to pass a list of
paths not to rmdir, whose default value is ["."], or something.

Elijah, thoughts?

But as a short-term fix, I think "--no-literal-pathspecs" is fine for
this code path.

Thanks.