Emily Xie <[email protected]> writes:
> An empty string as a pathspec element matches all paths. A buggy
> script, however, could accidentally assign an empty string to a
> variable that then gets passed to a Git command invocation, e.g.:
>
> path=... compute a path to be removed in $path ...
> git rm -r "$path"
>
> which would unintentionally remove all paths in the current
> directory.
>
> The fix for this issue comprises of two steps. Step 1, which warns
> that empty strings as pathspecs will become invalid, has already
> been implemented in commit d426430 ("pathspec: warn on empty strings
> as pathspec", 2016-06-22).
>
> This patch is step 2. It removes the warning and throws an error
> instead.
>
> Signed-off-by: Emily Xie <[email protected]>
> Reported-by: David Turner <[email protected]>
> ---
We started this at v2.11.0 at the end of November 2016, and this
cycle is expected to complete at around the end of July 2017, so
this patch makes it a 8-month deprecation cycle. I think that it
should be long enough.
Thanks.
> diff --git a/pathspec.c b/pathspec.c
> index 50f76ff..65e18b1 100644
> --- a/pathspec.c
> +++ b/pathspec.c
> @@ -638,12 +638,10 @@ void parse_pathspec(struct pathspec *pathspec,
> }
>
> n = 0;
> - warn_empty_string = 1;
> while (argv[n]) {
> - if (*argv[n] == '\0' && warn_empty_string) {
> - warning(_("empty strings as pathspecs will be made
> invalid in upcoming releases. "
> - "please use . instead if you meant to match
> all paths"));
> - warn_empty_string = 0;
> + if (*argv[n] == '\0') {
> + die("empty string is not a valid pathspec. "
> + "please use . instead if you meant to match
> all paths");
> }
> n++;
> }
The {} around a single statement becomes unnecessary, so I'll remove
them while queuing.
