Re: git-completion.tcsh

> Hi,
>
> Quoting Marc Khouzam <marc.khouzam@gmail.com>:
>>
>> Hi,
>>
>> I did notice the problem a while ago and had traced it back to the
>> fact that the bash completion scripts no longer adds the trailing '/'
>> at the end of directories.
>> Tcsh needs that '/' to know not to add that annoying extra space.
>>
>> Bash 3 needed to put it that trailing '/' but bash 4 did not.  Two
>> years ago (!) changes were made in commit
>> 3ffa4df4b2a26768938fc6bf1ed0640885b2bdf1 to allow bash 3 to work
>> without the trailing '/'.  That caused
>> the problem in the tcsh script.
>>
>> The thing is that with master of today, I don't see the problem any
>> more.  I can't tell you when it started working again.
>> What is interesting is that the reason it now works is that the
>> git-completion.bash script no longer returns anything
>> for the case you mention:
>>   git add f<tab>
>> Instead, it seems to rely on file completion only.
>
>
> I can't reproduce it with git-completion.bash from current master on its own
> on with bash 3.1.20(4) from MSysGit, it seems to work as intended here wrt
> tracked-file-aware file completion.
>
> Set up test repo with these commands:
>
>   git init
>   >tracked
>   git add tracked
>   >non-tracked
>   mkdir -p foo/bar
>   >foo/bar/somefile.c
>
> Now let's see what happens with 'git add':
>
>   $ git add <TAB>
>   foo/         non-tracked
>
> Note, that the file 'tracked' is not offered, so this is clearly not
> standard bash file completion, but our completion script.  Also note the
> trailing '/' in 'foo/'.
>
>   $ git add f<TAB>
>
> Just completes to 'git add foo/', no space after '/'.
> Add the file:
>
>   $ git add foo/bar/somefile.c
>
> Now let's see 'git rm':
>
>   $ git rm <TAB>
>   foo/     tracked
>
> Note, that the file 'non-tracked' is not offered, so again this comes from
> our bash completion script.
>
> Did you test the bash completion script on its own, or only through the tcsh
> wrapper?
> I'm on MSysGit now, so no tcsh or bash v4 at hand, and no time either, so
> can't dig further at the moment.
>