Re: [PATCH] pathspec: die on empty strings as pathspec

On Sat, Jun 10, 2017 at 01:28:54AM +0900, Junio C Hamano wrote:

Emily Xie [off-list ref] writes:

quoted

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 <redacted>
Reported-by: David Turner <redacted>
---

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.

That's long enough for people who actually ran the intermediate
versions.  But what about people on distros who jump from v2.10 or lower
straight to v2.14?

I think to catch them we'd literally need years on our deprecation
schedules. Maybe it's not worth caring about. That's an awful long time
for people who _are_ upgrading each version to see the warning. Of
course the end game in this case is that it becomes an error, so they'll
be notified either way. :)

I'm OK with this case being a relatively quick deprecation, but your
"long enough" made me wonder how we would decide that.

-Peff

[1] Debian stable is set to release in a week or so. People doing that
    stable upgrade will go from v2.1.4 to v2.11.0. So they won't
    actually skip the deprecation notice, but they'll probably live with
    the warning for 3 years or so.