Re: Git reset --hard with staged changes

["Pierre-François CLEMENT" <likeyn@gmail.com>]

2014-06-10 17:27 GMT+02:00 David Kastrup <dak@gnu.org>:
> Pierre-François CLEMENT <likeyn@gmail.com> writes:
>
>> 2014-06-10 1:28 GMT+02:00 Junio C Hamano <gitster@pobox.com>:
>>> Pierre-François CLEMENT <likeyn@gmail.com> 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

Yeah sorry, I just noticed the emails on the definition of what are
(un)tracked files
(http://thread.gmane.org/gmane.comp.version-control.git/251071/focus=251151),
as I didn't get them in my inbox for some reason. So staged files
which aren't in HEAD are also considered tracked -- which explains it
all. Someone told me that too on the "Git for human beings" Google
Group, but I couldn't find a definition that backs this in the man
pages (maybe the git-glossary would be a good place for it?), and the
one from the Git-Scm book only confused me in thinking the opposite.
Thanks for the clarification

--
Pierre-François CLEMENT
Application developer at Upcast Social