Re: [PATCH] grep: error out if --untracked is used with --cached

From: Taylor Blau <me@ttaylorr.com>
Date: Feb 8, 2021, 21:48 UTC
Message-ID: <YCGxos2vB6mgHOTA@nand.local>
In-Reply-To: <5bd9dce8f611c5fe380c9f58dbdfa2dc6d2fd51f.1612813249.git.matheus.bernardino@usp.br>

On Mon, Feb 08, 2021 at 04:43:28PM -0300, Matheus Tavares wrote:

Show 20 quoted lines

> The options --untracked and --cached are not compatible, but if they are
> used together, grep just silently ignores --cached and searches the
> working tree. Error out, instead, to avoid any potential confusion.
>
> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
> ---
>  builtin/grep.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/builtin/grep.c b/builtin/grep.c
> index ca259af441..392acf8cab 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -1157,6 +1157,9 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
>  	if (!use_index && (untracked || cached))
>  		die(_("--cached or --untracked cannot be used with --no-index"));
>
> +	if (untracked && cached)
> +		die(_("--untracked cannot be used with --cached"));
> +

Are these really incompatible? --untracked says that untracked files are searched in addition to tracked ones in the working tree. --cached says that the index is searched instead of tracked files. From my reading, that seems to imply that the combination you're proposing getting rid of would mean: "search the index,and untracked files".

That's a narrow use-case, but I couldn't think of a reason that it shouldn't work (but it's been a while since I've looked or thought much about the "git grep" code...).

Assuming that they are incompatible, though, a few thoughts:

Should this come before the "!use_index && (untracked || cached)" guard? right now passing all three options first says you can't combine --cached/--untracked with --no-index. Presumably the next invocation would come without --no-index, only to come back that the remaining options are incompatible.

I dunno. I'm thinking out loud, but it feels like this guard should come before the one above it, not after.

Should this appear in 'git-grep(1)' too? I guess not, since looking for "[iI]ncompatible" in that file turns up zero results.

Thanks, Taylor