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