Logical inconsistency in git reset

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]