Re: [PATCH v4 0/3] completion of 'git [-C <dir>] diff'

On Thu, Aug 6, 2026 at 6:38 PM Junio C Hamano <[email protected]> wrote:
>
> The primary motivation for this topic is that the command-line
> completion of 'git diff' does not handle paths (unlike 'git status'
> and 'git add') and instead relies on the default behavior of Bash
> command-line completion, which completes files in $PWD; this does
> not work at all with the '-C <directory>' option.
>
> This series teaches the completion machinery to complete revisions
> (unless '--' exists), then tracked paths, and then untracked paths,
> before letting the Bash default kick in.  This way, we correctly
> complete 'git diff' command line even when '-C <directory>' is in
> effect.

Nice.  :-)

> The tests are the only changes relative to v2.  In the step where
> tracked paths are completed, v2 did not demonstrate that untracked
> ones are *not* completed at the same time.  Now we do by having
> untracked 'file3' next to 'file1' and 'file2' that are tracked.  In
> the last step, we demonstrate untracked paths that do not share
> prefix with refs or tracked paths are completed, with or without the
> "-C <dir>" option.

I found this paragraph slightly hard to parse.  I think this means the same as:

Only the tests changed since v2.  The tracked-paths step now also
shows that untracked paths are not mixed in: an untracked 'file3'
next to tracked 'file1'/'file2' means "git diff f" completes only the
latter two.  The untracked-paths step shows that an untracked path
which shares no prefix with a ref or tracked path still completes,
with or without "-C ".

(Not that it matters, since this is just the cover letter, but...)

>  1/3: completion: no-op refactoring of diff completion
>  2/3: completion: complete tracked paths for 'git diff'
>  3/3: completion: 'git diff' completes untracked paths as a last
>         resort

I found two minor nits in the first two patches, and didn't spot any
issues with the third patch.