Jeff King <peff@xxxxxxxx> writes: > On Thu, May 28, 2020 at 03:21:34PM -0700, Junio C Hamano wrote: > >> > 1. Deprecate the current behavior in the documentation and release >> > notes, encouraging people who want literal matching to use >> > --literal-pathspecs or the ":(literal)" magic. AFAICT we've >> > supported these since at least 2013 for this command, so it should >> > be safe to use unconditionally. >> > >> > 2. Add a new option, "--use-pathspecs" or similar, that switches the >> > matching code to use match_pathspec(). That lets people use the new >> > feature immediately if they want to. >> > >> > 3. When --use-pathspecs is not in use, warn to stderr about any >> > wildcard characters in the input. That reinforces the deprecation >> > notice in (1) and is likely to get more people's attention. >> >> Hmph, if we are serious about deprecation and migration, I would >> image that in stage #1, we should do this check already. When >> "--literal-pathspecs" is NOT in use, if a pathspec would change its >> meaning if not taken literally (e.g. has glob letters, begins with >> :-magic introducer, etc.), we warn and do so from the very beginning >> of the migration process. > > Yeah, sorry, I meant these three steps to all happen at once. > > Technically we don't need step (2) in there for the deprecation, but I > think it lets people adjust to the new world order as their solution to > avoid the warning (though I guess literal-pathspecs would also prevent > the warning; we wouldn't be looking for "*" in the input so much as > checking whether the parsed pathspec contains a wildcard). I do agree that letting early adopters experiemtn is a great and necessary step. And I think I misread the condition you wrote in your 3.; I do agree that we should warn when --use-pathspecs is not in use, but if --literal-pathspecs is in use, then the user wants to match literally even when the pattern has globs and :-magic introducer sequence, so we shouldn't warn. Thanks.
