Re: Git-add completion should show full file paths

[dana <dana@xxxxxxx>]

On 26 Apr 2020, at 17:57, Amyn Bennamane <amynbe@xxxxxxxxx> wrote:
> Can anyone here comment on the above idea and/or suggest a way to
> implement this?

I've often wished it worked the way you suggested, but not always.

If i have two unstaged files like a/b/c/d/e/foo and a/b/c/d/f/bar, then having
it complete the full paths is useful, because there are only a few and i don't
want to repeatedly tab (or write out the correct pattern / abbreviated path)
to recurse into those directories.

But if i have 20 unstaged files that are all under a/b/c/d/e, i would rather
the completion assist me with adding that entire directory than show me a
million giant file paths.

I guess what Daniel is suggesting is basically an on/off switch for
_multi_parts's intended function, and you can turn it off for git if you want.
That'd work fine as long as you don't expect to run into the latter case very
often.

I wonder if it could be more intelligent though — maybe this style could take
an integer that acts as a threshold for whether it should work the normal way
or the 'dumb' way? Like if there are more than x files with the same prefix or
whatever. Not sure how you'd calculate it, but something like that.

Also, whether it's like that or just a boolean, it seems like you'd also need
to consider how recursive completion should work, or if it should, in the
'dumb' case. I think users are accustomed to being able to expand like
f/b/b<TAB> -> foo/bar/baz with file paths, and it would be confusing if that
only worked some of the time... though they would have to go out of their way
to set it like that, so idk

dana