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

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

[Junio C Hamano]

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.

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

[Stefan Beller]

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

> 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".

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


>
> Thanks.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> On Thu, Mar 24, 2016 at 2:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Discuss.
>
>> 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".
>
> Completely side tracking thought: Have you considered ignoring
> whats-cooking.txt+ locally?

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

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

[Junio C Hamano]

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

> Stefan Beller <sbeller@google.com> writes:
>
>> On Thu, Mar 24, 2016 at 2:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Discuss.
>>
>>> 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".
>>
>> Completely side tracking thought: Have you considered ignoring
>> whats-cooking.txt+ locally?
>
> The point is that I shouldn't have to.  I wasn't asking for a
> workaround.

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.

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

[Junio C Hamano]

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

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

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

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

[Stefan Beller]

On Thu, Mar 24, 2016 at 3:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> On Thu, Mar 24, 2016 at 2:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Discuss.
>>
>>> 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".
>>
>> Completely side tracking thought: Have you considered ignoring
>> whats-cooking.txt+ locally?
>
> The point is that I shouldn't have to.  I wasn't asking for a
> workaround.

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.

> 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>"?).

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.

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

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?)

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

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

>> 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>"?).
>
> 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.

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").

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

[Jacob Keller]

On Thu, Mar 24, 2016 at 3:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>>> 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>"?).
>>
>> 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.
>
> 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").
>
>

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