Ramkumar Ramachandra <artag...@gmail.com> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to