On Thu, May 30, 2013 at 10:49:32AM +1000, Erik de Castro Lopo wrote: > Look at this commit: > > git log --name-status f51ac745a6d4087cc4d77a3cee01db0412955c79 > > and notice that one of the files modified is "pib/chkpib2.7", so lets > look at the parent version of that file: > > git show f51ac745a6d4087cc4d77a3cee01db0412955c79^:pib/chkpib2.7 > > which produces no output and exits with 0 status. > > However looking at the diff for commit f51ac745a suggests that while > the file pib/chkpib2.7 may have existed before that commit, it must > have been empty (ie zero length). > > Does this explanation make sense? Yes, that is what I would expect git to do in such a situation. You can inspect it further, too: $ git rev-parse f51ac745^:pib/chkpib2.7 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 That's the sha1 of the blob containing the content. You can investigate information about that object like this: $ git cat-file -t e69de29b blob $ git cat-file -s e69de29b 0 $ git cat-file blob e69de29b Of course since its size is 0, the last one is not that interesting. :) You could also just look at the tree, which gives similar information: $ git ls-tree -lr f51ac745^ | grep pib/chkpib2.7 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 pib/chkpib2.7 Hope that helps. -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