> > The problem is, if the directory name *already* has a slash, Bash adds > > another slash! > > So bash users do see the trailing slash because bash adds one to > what we compute and return, which we do strip the trailing slash > exactly because we know bash will add one.
The problem is slightly more obscure than that, and I wonder if it should be documented somewhere in the bash script? Manlio explained in a previous exchange with me, that bash will properly deal with an existing trailing slash when doing the completion on the command-line, but will screw it up by adding a second slash when dealing with multiple possible completions and printing those for the user to choose from. For example: $ git status # On branch tcsh_next # Untracked files: # (use "git add <file>..." to include in what will be committed) # # fish/ # fishing/ nothing added to commit but untracked files present (use "git add" to track) $ git add fish<tab> fish// fishing// <-------- notice the double slashes $ git add fishi<tab> # will complete the command line properly to the below, with a single slash. $ git add fishing/ > Because tcsh completion > uses what we compute directly, without bash massaging our output to > add the trailing slash, it needs some magic. Yes, that is right. > OK, that makes sense. It was this part from the originally proposed > log message: > > >> ... Such completions do not add the '/' at the end of directories > >> for recent versions of bash. However, the '/' is needed by tcsh, > >> ... > > with a large gap between the two sentences that fooled me, and the > explanation in your message helped to fill the gap to understand the > situation better. Sorry about the lack of details. I'm see more and more the importance of these commit messages :) > Perhaps > > ... for recent versions of bash, which will then add the > trailing slash for paths that are directory to the result of > our completion. The completion for tcsh however uses the > result of our completion directly, so it either needs to add > the necessary slash itself, or needs to ask us to keep the > trailiing slash. This patch does the latter. > > or something? How about the following, which gives a little more detail about the solution for tcsh? I think it is worth putting the below extra details because I feel a mistake could easily be made about this trailing slash issue, which I had gotten wrong for my own version of the script for a couple of weeks, before figuring out the mistake. Handle path completion and colon for tcsh script Recent enhancements to git-completion.bash provide intelligent path completion for git commands. Such completions do not provide the '/' at the end of directories for recent versions of bash; instead, bash itself will add the trailing slash to directories to the result provided by git-completion.bash. However, the completion for tcsh uses the result of the bash completion script directly, so it either needs to add the necessary slash itself, or needs to ask the bash script to keep the trailing slash. Adding the slash itself is difficult because we cannot easily tell if an entry of the output of the bash script is a directory or something else. For example, assuming there is a directory named 'commit' in the current directory, then, when completing git add commit<tab> we would need to add a slash, but for git help commit<tab> we should not. Figuring out such differences would require adding much intelligence to the tcsh completion script. Instead, it is simpler to ask the bash script to keep the trailing slash. This patch does this. Also, tcsh does not handle the colon as a completion separator so we remove it from the list of separators. Signed-off-by: Marc Khouzam <marc.khou...@ericsson.com> Thanks Marc -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html