Subject: Re: Git reset --hard with staged changes

From: David Kastrup <[email-masked]>
Date: Tue, 10 Jun 2014 17:27:26 +0200

Pierre-François CLEMENT <[email-masked]> writes:

> 2014-06-10 1:28 GMT+02:00 Junio C Hamano <[email-masked]>:
>> Pierre-François CLEMENT <[email-masked]> 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