From: David Kastrup Date: Tue, 10 Jun 2014 15:27:26 GMT Subject: Re: Git reset --hard with staged changes Message-ID: <871tuwss2p.fsf@fencepost.gnu.org> In-Reply-To: Pierre-François CLEMENT writes: > 2014-06-10 1:28 GMT+02:00 Junio C Hamano : >> Pierre-François CLEMENT writes: >> >>> Hm, I didn't think of "git apply --index"... Makes sense for this >>> special use, but I'm not sure about the other use cases. >> >> Try merging another branch that tracks a file your current branch >> does not know about and ending up with conflicts during that merge. >> Resetting the half-done result away must remove that new path from >> your working tree and the index. > > Hm I see. Even though the documentation doesn't make it very clear > about what happens to such files, it turns out the scenario we > stumbled upon seems to be the special use case after all. Thanks for > shedding some light on this :) I wonder why does git-reset's hard mode > not always remove untracked files then? Because it never removes them? Git only removes files once it tracks them. This includes the operation of removing _and_ untracking them, like with git reset --hard. The only command which explicitly messes with untracked files is git-clean. -- David Kastrup