Re: [PATCH v3] tab completion of filenames for 'git restore'

From: David Cantrell <david@cantrell.org.uk>
Date: Mar 17, 2022, 22:16 UTC
Message-ID: <6fd18785-500b-a83e-a6d7-1e7fe69fe4b6@cantrell.org.uk>
In-Reply-To: <xmqqsfribuan.fsf@gitster.g>

On 16/03/2022 00:44, Junio C Hamano wrote:

> "David Cantrell via GitGitGadget" <gitgitgadget@gmail.com> writes:
>> If no --args are present after 'git restore' it assumes that you want
>> to tab-complete one of the files with unstaged uncommitted changes.
> What do you mean by "--args" in this sentence?  Dashed-options?

Yes.

Show 8 quoted lines

> I am getting the same set of files whose name begins with 'a' from
> these two:
> 
>   $ git restore a<TAB>
>   $ git restore --staged a<TAB>
> 
> so, with or without --dashed-options, we complete one of the files,
> whether they have any modifications.

If --staged is present I think it falls back to the standard behaviour of attempting to complete to any file it can find

Show 32 quoted lines

> Perhaps you meant to say more like:
> 
>      When completing a non-option argument to 'git restore', the
>      command line completion support offers names of the files
>      present in the working tree as candidates.
> 
> to describe the status quo; to hint what the shortcoming of the
> current behaviour is, we may want to add a bit more, perhaps
> append the following at the end of that first paragraph:
> 
>      But many of these files may not have any changes, and running
>      "restore" on them would be a no-op.  Listing only the files, to
>      which doing "restore" is not a no-op, would reduce the clutter.
>      
> Then we'd continue with the solution, while explaining why the exact
> choice between modified vs committable was made:
> 
>      Offer only the files that are different from the index, to match
>      the default behaviour of "git restore" that checks out the
>      contents last added to the index to the working tree.  We could
>      instead show the files that are different between the index and
>      HEAD, and that is more suittable if "git restore --staged" is
>      being completed, but this should do for now.
> 
> or something.  The last part is written in such a way to explicitly
> signal to future developers that we know we did not do a perfect job
> and we do not mind if they extend the logic to use something other
> than "--modified" when appropriate.  For example, they could build
> on this solution to make it inspect the command line for "--staged"
> and "--source" and drive "diff-index" differently to grab the paths
> that are offered.  We just do not do that at least for now, but we
> have no objection if other people do so in the future.

That makes sense.

> Thanks.  Will queue as-is for now.

Thank you.

-- 
David Cantrell