Elijah Newren <newren <at> gmail.com> writes: > Anyway, Eric wasn't really talking about ignoring files, since he was > explicitly adding them for the next commit. It's just that at some > point he changed his mind and decided he didn't want to include any of > the changes he had already made in the next commit, but was surprised > when git reset --hard deleted the files from both the index and > working copy instead of just the index. git reset --hard really is > meant for throwing away unwanted stuff (particularly including in the > working directory), but I can see how he may have expected behavior > more along the lines of git rm --cached for those particular files. I > don't agree with that viewpoint (I see files as tracked as soon as you > stage it, not once you commit it), but I can see where the expectation > comes from. > > Just my thoughts, > Elijah Yes, you have a 100% correct understand of what I'm trying to say. But can you see a downside to "git reset --hard" treating newly added files as "git reset"? Wiping out existing files (with no realistic recovery) is a bit harsh, isn't it? Especially when AFAICS there's no downside to leaving the untracked files as they were before they were "git add"-ed. - Eric -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
