Re: git show doesn't work on file names with square brackets

From: Jeff King <peff@peff.net>
Date: Feb 10, 2016, 15:45 UTC
Message-ID: <20160210154510.GB19867@sigill.intra.peff.net>
In-Reply-To: <xmqqlh6u6d8v.fsf@gitster.mtv.corp.google.com>

On Mon, Feb 08, 2016 at 02:36:32PM -0800, Junio C Hamano wrote:

Show 18 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > But having looked at this, I can't help but wonder if the rule should
> > not be "does the file exist" in the first place, but "is the file in the
> > index". This dwimmery is about commands like "log" that are reading
> > existing commits. I cannot think of a case where we would want to
> > include something that exists in the filesystem but not in the index.
> 
> Yeah, checking in the index, once it is loaded, is reasonably quick
> check.  A path that is not in the index or the current HEAD may or
> may not exist on the filesystem, so at some point you would need an
> explicit disambiguation anyway, and the reason why we check the
> filesystem is not because that is conceptually better than checking
> in the index but merely because "does lstat(2) tell us the path is
> there?" check was fairly a cheap way on the platform the system was
> primarily developed on initially.  Looking it up from HEAD would be
> a lot more heavyweight and would not buy us anything, but looking it
> up in the index may turn out to be comparable to a single lstat(2).

Yeah, I had a notion that looking in the index would not be all that expensive, since we often load it anyway. But this _is_ "git log" we are talking about, which does not otherwise need to read the index at all. I suspect lstat(2) is way faster if you have a huge repo, as it is should be constant-ish, as opposed to O(size-of-index).

Show 5 quoted lines

> I dunno.  I have a suspicion that anything conceptually more
> expensive than a single lstat(2) is probably not worth doing, as
> this "sometimes you do not have to give --" is merely a usability
> hack, and we have to always do "git log -- removed-sometime-ago"
> to find where in the history a certain path was lost.

Yeah, it just seemed a shame to me that things which clearly _aren't_ ambiguous to any sane viewer would be reported as such by git. I think the "--" DWIM has worked so well precisely because people do not have silly-named files in their repositories, so it Just Works most of the time. The wildcard rule switches it from "you put a file named HEAD in your repository, now you pay the price for being silly" to "whoops, everything with a metacharacter is now ambiguous".

-Peff