Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Jun 7, 2013, 17:30 UTC
Message-ID: <CALkWK0=D7sHLgptWkFHma1FoS-zdifHqXnuuBKhkyuszgEJ0Xw@mail.gmail.com>
In-Reply-To: <20130607000006.GA25731@goldbirke>

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

Show 6 quoted lines

> 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.