On Thu, Mar 24, 2016 at 3:55 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html