[RFD] minor frustration in 'git add' pathname completion

It seems that "git add foo<TAB>" completes to files

 (1) whose names match 'foo*',

 (2) that are not ignored (i.e. "foobar~" will not be offered for
     Emacs users), and

 (3) are different from the index.

The last one is somewhat frustrating at times. For example, I keep a backup version of whats-cooking.txt in the working tree that I use to manage the 'todo' branch as whats-cooking.txt+, and this is not explicitly "ignored". Most of the time, I have changes to the real file, so

    $ git add whats<TAB>

would complete to "whats-cooking.txt" (because there are two candidates, "whats-cooking.txt" and "whats-cooking.txt+", and the first completion is done up to the common prefix) and everything is good.

Immediately after I did "git add whats-cooking.txt", however, because of (3), the completion for

    $ git add whats<TAB>

offers "whats-cooking.txt+", because that is the only candidate that passes all three criteria. This is quite annoying and even dangerous, because it does not happen most of the time.

I am wondering if there is a downside to removing (3) from the completion logic.

Discuss.

Thanks.

On Thu, Mar 24, 2016 at 2:44 PM, Junio C Hamano <gitster@pobox.com> wrote:

Completely side tracking thought: Have you considered ignoring whats-cooking.txt+ locally?

WC+ is a local thing to your repo, so you'd want to prefer $GIT_DIR/info/exclude over .gitignore.

You wish to ignore WC+ by git, so make it be ignored, instead of changing the git add rules. Your proposal feels like fixing the symptoms instead of the root cause.

I can see (3) being useful as it narrows down the list by a lot, I would imagine.

As I rarely use git add, but prefer git-gui, I have no experience though for git-add completion, but if you had one conflict after a bad merge you can just do git add <TAB> to get that file(?), so I guess people use it.

Stefan

Stefan Beller <sbeller@google.com> writes:

The point is that I shouldn't have to. I wasn't asking for a workaround.

Junio C Hamano <gitster@pobox.com> writes:

More importantly, I suspect that it would not work very well as a workaround.

If I were to explicitly ignore that file, then even though I know whats-cooking.txt is not ignored,

    $ git add whats-coo<HT>

would not offer anything. I'd be left scratching my head, wondering if I mistyped the early part of the filename (e.g. "wahts-coo<HT>"?).

I think the source of the irritation comes from the fact that the command line completion can only say "I do not see anything worth adding with the prefix you gave me" by not completing the prefix string to anything, and it cannot explain why it thinks so (e.g. "because the path that matches the prefix is up-to-date and there is no point adding it again" vs "because there is no path that matches the prefix, perhaps you made a typo?"). Loosening (3) might be an effective way to address it.

On Thu, Mar 24, 2016 at 3:06 PM, Junio C Hamano <gitster@pobox.com> wrote:

It is not a workaround. You want to have an untracked file in a repository, but you want git add to ignore it, which sounds like the definition of the ignoring mechanism.

Well, git add cannot do anything with either of the files, so why would it offer to complete to one of them?

In an ideal world it would tell you whats-cooking.txt doesn't need adding and whats-cooking.txt+ is ignored locally so excluded from being added.

Uh, is there a good way to test auto completion if at all in our test suite? (Would we want such a thing to be tested?)

Stefan Beller <sbeller@google.com> writes:

Exactly my point that you omitted from your quoting ;-)

Because the completion cannot give such an explanation, the behaviour gives an unnecessary confusion to the user. If it offered whats-cooking.txt as a candidate, at least the behaviour would make sense to the user. "Doesn't need adding" is quite different from "must not be added". In other words, "git add A && git add A" does not hurt, but "git add A~" would because the latter would only makes you see unnecessary error message ("You need -f if you really mean it").

On Thu, Mar 24, 2016 at 3:55 PM, Junio C Hamano <gitster@pobox.com> wrote:

I use this feature every day such that I can just do:

git add <tab>

and it cycles through all the available files which differ (thus could be added). If it didn't do (3) then this would tab complete to every file, every time, which is not what I expect it to do. It is definitely something one has to get used to, but I know I prefer it the way that it is.

For your case, I think local ignore is the right solution. Narrowing the list is really a useful feature of add's tab completion.

Thanks, Jake

Junio C Hamano <gitster@pobox.com> writes:

Eh, please don't.  Somehow this no longer reproduces for me.