On Fri, 21 Apr 2017 13:54:30 -0700 (PDT) vvs <vvs...@gmail.com> wrote:
> 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. Is that intended? I found this behavior somewhat confusing > and don't see it documented anywhere. All forms of `git reset`, if not given a specific commit/tree-ish, take HEAD as the commit/three-ish to take the data from. That is, your git reset --hard is actually git reset --hard HEAD So if you did not have an entry for a file in the index by the time you run that command but you do have an entry for that file in the tree referenced by the commit at HEAD, that file will be "touched", if needed. When you do git reset --mixed git reset --hard The first command replaces the index with the contents of HEAD while the second re-does that once again and then updates the working tree with what's in the HEAD. I, for one, fail to see how that could be different from calling `git reset --hard` alone. So either I fail to understand your setup or you failed to clearly convey it or maybe there's a problem with your methodology of observing what was changed. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
