[[!comment format=mdwn
 username="joey"
 subject="""comment 1"""
 date="2018-11-12T16:13:26Z"
 content="""
I see this too. Note that it only affects tab
completing "git annex"; tab completing "git-annex"
works correctly for filenames with spaces and AFAICS
other problem characters.

It used to be that git-annex's tab completion for "git annex" was only used
after the user tab completed "git-annex" which loaded the function.
That has changed; git now loads the git-annex completion. Which is good;
I asked the git devs a long time ago to add that. But the change means this
problem is more visible. I don't think the problem is new though.

[[!commit 07c108e70e2df354d1478cbbec3630d2409d9d32]]
dealt with the same problem affecting "git-annex" tab completion.
The underlying problem is a bug in optparse-applicative, which
completes filenames without escaping them.
So that commit made the "git-annex" completion use "-o bashdefault -o default"
which bypasses the optparse-applicative completion for filenames and lets
bash handle them. It didn't seem to deal with "git annex" completion.

I see that git uses `__gitcomp_file_direct` when using eg `git ls-files`
to list filenames. It seems that "compopt -o filenames" along with
IFS=newline fixes it. I'll put the same approach into the git-annex script.
"""]]
