Re: [PATCH] completion: complete tracked paths for 'git diff'

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 3, 2026, 13:41 UTC
Message-ID: <xmqq33wv1fts.fsf@gitster.g>
In-Reply-To: <anAqfqcEueSKmAH+@szeder.dev>

SZEDER Gábor <szeder.dev@gmail.com> writes:

Show 5 quoted lines

> I think we should check whether the '--no-index' option is present on
> the command line, and simply not call __git_complete_index_file() if
> it is, to let Bash list all paths; i.e. each of those calls should be
> protected by an additional 'if test -z "$(__git_find_on_cmdline
> "--no-index")' condition, perhaps.

Ah, I did not think of the "we made 'git diff' work without Git" mode at all.

But I would avoid scanning the command line for '--no-index' for two reasons:

 (1) "git diff -S --no-index maint master" would not give you the
     '--no-index' mode.

 (2) When run outside the working tree of a repository, you do not
     have to say '--no-index'.

These make detecting the "'git diff' but not Git" mode tedious and error-prone.

I have not tried this, but if we arranged the code to fall back further to Bash-native "paths in $PWD" after the completion code in the posted patch found nothing, would it be sufficient?

When trying to complete an untracked file in the working tree of a repository, if the file shares the same prefix with a tracked file, you cannot complete the untracked file without a prefix long enough to disambiguate it from the tracked one. Such a prefix may not even exist (e.g., 'foo' is tracked and 'foo~' is untracked; when you type "git diff --no-index foo<TAB>", you get 'foo' but not 'foo~', so you end up typing 'foo~' in full). In that sense, it is a regression, but supporting Git usage is the primary mission of 'git diff', so the trade-off may not be so bad.

Thoughts?