{"thread":{"id":"45779","subject":"Logical inconsistency in git reset","startedAt":"2017-04-23T16:01:18Z","lastAt":"2017-04-23T16:01:18Z","messageCount":1,"participants":["vvs"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"317562","messageId":"CAM1zWBtfgHT=pT0pidQo1HD=DfrXLG3gNaUvs0vZKvYfG1BHFw@mail.gmail.com","threadId":"45779","inReplyTo":null,"subject":"Logical inconsistency in git reset","fromName":"vvs","fromEmail":"vvs009@gmail.com","sentAt":"2017-04-23T16:01:05Z","receivedAt":"2017-04-23T16:01:18Z","isPatch":false,"sender":{"key":"vvs009@gmail.com","avatar":null},"body":"Dear list\n\nLike it was suggested on git-users list I'm forwarding the original\nmessage here.\n\nI found out that \"git reset --hard\" produced different outcome\ndepending on current index content, i.e. when there is no entry for a\nfile in working tree it actually changed that file. While on the\ncontrary, if you use \"git reset --mixed\" right before that, the file\nwon't be touched. This affects make, which thinks that the file was\nchanged.\n\nMore detailed discussion and test cases can be found here:\nhttps://groups.google.com/forum/?hl=en#!topic/git-users/9ziZ6yq-BfU\n\nI could just add to that argument that this issue is certainly looks\nlike a logical inconsistency to an average user. The git operations\nare checking an index entry for the file in working tree but they\ndoesn't fill that entry in the first place. Shouldn't this be\nconsidered as a kind of uninitialized pointer problem? And there is\nthat useful abstraction that --hard should include --mixed semantics.\n"}]}