On Saturday, April 22, 2017 at 4:10:17 PM UTC+3, Konstantin Khomoutov wrote: > > 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. >
Yes, of course. I was just referring to relevant parameters for brevity. > 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. > There are legitimate uses when you have to revert your index to a previous state where there is no entry for some files in working tree. When you try to bring the working tree back to the specific commit, you'd encounter the observed behavior. As a test you could just issue "git read-tree --empty" to remove all index entries. After reading the documentation I was under impression that "git reset --hard" includes "--mixed" which in turn includes "--soft", but the actual behavior is different. It breaks that abstraction and confuses make to recompile everything unnecessarily. Using "git reset --mixed" is a workaround and I fail to see any sense in actually making it a requirement. This seems more like a git bug to me. -- 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.
