SZEDER Gábor wrote: > the one at the top because > of the reasons given in $gmane/226272
Sorry about the delay: I went to sleep for a couple of days :P > the one at the bottom because > of the misleading commit message (__git_complete_file() always > completed refs first as part of the ref:file notation, so it worked > just fine except for the ref1...ref2 notation; the real reason for > calling __git_complete_revlist_file() for difftool is to make clear > that difftool takes ref1...ref2:file, too). How am I (or anyone else) supposed to know the "intended" meaning __git_complete_file()? The implementation is just an alias to __git_complete_revlist_file(), so I looked at the name and guessed that it was supposed to complete files; now you tell me that it was intended to complete any revspec except revision ranges (what does that have to do with "file" again?). I suppose digging through the history would've told me, but I really didn't bother for such a trivial non-functional change. If you ask me, you should clamp down on spurious completions everywhere uniformly, if that is what you want (I personally have no interest in the topic). I see no reason to keep a badly named function around. -- 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
