On Sun, Feb 28, 2010 at 04:49:15PM +0100, Markus Heidelberg wrote: > It can be reproduced in a bare repository with > $ git show :anyfile > > I didn't find a recipe for reliably reproducing it in a repository with > working tree, it happened depending on the filename and the repository. > $ git show :nonexistentfile I can confirm the bug here. It is not about bareness, but having no index makes it easy to trigger, since it is easy to walk past the end of a zero-length index. But it is not restricted to that case: > It seemed to happen more likely with high letters (x, y, z) as the first > character of the filename. This always worked for me: > $ git show :z > But I found this to be too strange to be added to the commit message. That's because cache_name_pos returns the position where the entry _would_ be if it existed (well, the negation minus one, but the intent is you can reconstruct that position if you did want to insert it). The diagnose_invalid function then looks at that entry to see if it is a missing filename or a missing stage. But of course, if it would be inserted past the end of what exists in the index, there is nothing to look at. So your ":z" is simply about being at the end of the index, which is sorted alphabetically. Which means your fix (to make sure we are not at the end) is correct. -Peff -- 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