Manlio Perillo <manlio.perillo@xxxxxxxxx> writes: > Il 18/12/2012 18:53, Junio C Hamano ha scritto: >> [jch: cc'ed git-completion experts to review implementation details] >> >> Manlio Perillo <manlio.perillo@xxxxxxxxx> writes: >> >>> The git-completion.bash script did not implemented full, git aware, >>> support for completion, for git commands that operate on files within >>> the current working directory or the index. >>> >>> For these commands, only long options completion was available. >> >> I find the "long options completion" is a misleading phrase. It >> sounds as if you changed the current completion that does not >> complete "git commit -<TAB>" but does "git commit --<TAB>" to >> complete the short options (e.g. "git commit -c"), but I do not >> think that is the topic of this patch. >> > > It does not sound misleading to me. > I'm saying that the git-completion.bash script only implemented > completion for long options, but not for file names in the current > working directory. > > Do you think I should rewrite the subject and the log message introduction? The subject sounds fine; it is just "It only does long options" sounded as if it were viewing the lack of "short options" support as an issue. In other words, my knee-jerk answer to "long options, as opposed to what???" question was "short options", not "files". If the phrase were "It only does options", the question would become "options as opposed to what???", which may have given me a chance to guess "files" as the answer to that question. > As an example, something like this in the subject: > > git-completion.bash: improve some git commands completion I think the original is better; you do not touch any "options", either long or short. You are improving "paths", and the original is much clearer on that point. > > and in the message: > > The git-completion.bash script did not implemented full, git aware, > support for completion, for git commands that operate on files within With s/for completion/to complete paths/, it would be perfect. You do not touch options, and this new log message does not talk about it. Much nicer than the one that was posted. > Note that the performance is the reason why I suggested, in a previous > email, that git should have some more options to format data in custom ways. > As an example, there is no way to tell ls-files to not recurse > directories, and there is no way to also get the file type. To ls-files, no-recurse is an idiotic thing to ask. The index is a flat structure that is read as a whole. There is no recursion involved. -- 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