Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > Junio C Hamano wrote: >> Revert 77c1305 and 3c3b46b > > The core of the argument seems to be that > __git_complete_revlist_file() is a misleading name for the completion > done by archive and ls-tree, but __git_complete_file() is somehow a > less misleading name? Irrespective of what the valid completions of > the various commands are, I want to know which completion function > will be _used_ when I'm reading the script. And that is > __git_complete_revlist_file(). > > To me, it looks like mega-bikeshedding; a huge amount of time and > effort going behind a non-functional variable rename (and the best > part? the rename isn't getting us a "better" name; just a "historical" > name). But whatever. To me the most important part is that we have two separate functions that are used consistently by how the completion is to be done for their users. The complete-file variant can then lose the A..B range completion, and then be given a better name than FILE to express what it does if somebody can find one. When it happens, the same better name should be used to rename complete-revlist-FILE by replacing the "FILE" part. I initially thought that FILE referred to the pathspecs (i.e. the last part in "log <rev> <file>"), and felt it was strange to call it FILE. Perhaps that (i.e. it not being pathspec) is what you find it misnamed). But it turns out that in the context of these functions it refers to "what users consider paths in objects stored in the object database" (as opposed to working tree paths). That is what ls-tree would take (i.e. <tree-ish> and <tree-ish>:<path>). And I do not offhand think of a better name myself to strongly oppose to using the word FILE to refer to what it does. -- 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