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". If the proposal were instead to add a certain type of pathspec that is case-insensitive, 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  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.  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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html