Logical inconsistency in git reset

Dear list

Like it was suggested on git-users list I'm forwarding the original message here.

I found out that "git reset --hard" produced different outcome depending on current index content, i.e. when there is no entry for a file in working tree it actually changed that file. While on the contrary, if you use "git reset --mixed" right before that, the file won't be touched. This affects make, which thinks that the file was changed.

More detailed discussion and test cases can be found here: https://groups.google.com/forum/?hl=en#!topic/git-users/9ziZ6yq-BfU

I could just add to that argument that this issue is certainly looks like a logical inconsistency to an average user. The git operations are checking an index entry for the file in working tree but they doesn't fill that entry in the first place. Shouldn't this be considered as a kind of uninitialized pointer problem? And there is that useful abstraction that --hard should include --mixed semantics.