Re: [PATCH/RFC] blame: respect "core.ignorecase"

[Jeff King <peff@peff.net>]

On Sun, Sep 09, 2012 at 12:24:58PM -0700, Junio C Hamano wrote:

> Having said all that, I am not sure if the "fixing" is really the
> right approach to begin with.  Contrast these two:
> 
>     $ git blame MakeFILE
>     $ git blame HEAD -- MakeFILE
> 
> The latter, regardless of core.ignorecase, should fail, with "No
> such path MakeFILE in HEAD".  The former is merely an extension to
> the latter, in the sense that the main traversal is exactly the same
> as the latter, but on top, local modifications are blamed to the
> working tree.
> 
> If we were to do anything, I would think the most sane thing to do
> is a smaller patch to fix fake_working_tree_commit() where it calls
> lstat() and _should_ die with "Cannot lstat MakeFILE" on a sane
> filesystem.  It does not currently make sure the path exists in the
> HEAD exactly as given by the user (i.e. without core.ignorecase
> matching), and die when it is not found.

Yes, I think that is the only sensible thing here. The rest of this
email is me essentially me agreeing with you and telling you things you
already know, but I had a slightly different line of reasoning, so I
thought I would share.

As far as the original patch, if you are going to change blame, then it
is only logical to change the whole revision parser so that "git log --
MAKEFILE" works. And I do not think that is a direction we want to go.

core.ignorecase has never been about "make git case-insensitive". Git
represents a case-sensitive tree, and will always do so because of the
sha1 we compute over the tree objects. core.ignorecase is really "make
case-sensitive git work around your case-insensitive filesystem"[1].

If the proposal were instead to add a certain type of pathspec that is
case-insensitive[2], that would make much more sense to me. It is not
violating git's case-sensitivity because it is purely a _query_ issue.
And it is a feature you might use whether or not your filesystem is case
sensitive.

-Peff

[1] I was going to submit a patch to Documentation/config.txt to make
    this more clear, but IMHO the current text is already pretty clear.

[2] I did not keep up with Duy's work on pathspec magic-prefixes (and I
    could not find anything relevant in the code or documentation), but
    it seems like this would be a logical feature to support there.