2014-06-03 17:03 GMT+02:00 André Hänsel <an...@webkr.de>: > On Tuesday, June 3, 2014 2:16:44 PM UTC+2, Pierre-François CLEMENT wrote: >> >> It seems logical to me that git-reset <http://git-scm.com/docs/git-reset>'s >> --hard option resets everything, what's staged, what's not, etc. I see it >> as a *"make my working dir in the exact same state as this commit"* >> command, which I believe it is. If you don't want it to reset your index or >> working dir or both, see git-reset <http://git-scm.com/docs/git-reset>'s >> other modes. >> > > Well, that's the point. Currently it's *not* a "make my working dir the > exact same state" tool, as far as untracked files are concerned. It always > leaves untracked files alone, there's not even an option to delete them. I > feel the staged file should be left alone, too. (Just the index should be > reset, so then it's unstaged again.) >
Ah, my mistake I've misread you in the first place. You're right, it feels natural they should return to their "untracked" state rather than being deleted. And it sounds definitely possible to implement: git could just check if the file was tracked or not before deleting it, the same way it can tell the file has been "added" or "modified". -- 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.
