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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 16/03/2022 00:44, Junio C Hamano wrote:
"David Cantrell via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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.

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

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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux