Pierre-François CLEMENT <likeyn <at> gmail.com> writes:
> 2014-06-10 17:27 GMT+02:00 David Kastrup <dak <at> gnu.org>:
>> Pierre-François CLEMENT <likeyn <at> gmail.com> writes:
>>
>>> ...
>>>
>>> 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
>
> ... 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
Jumping into this conversation two years later*. There's confusion about what
constitutes a tracked file for git reset --hard, and good reasons for git reset
--hard's behavior. Nevertheless, I think we can all agree that the man page
entry for git reset --hard is woefully deficient:
--hard Resets the index and working tree. Any changes to tracked files in the
working tree since <commit> are discarded.
This should be clarified to define what a tracked file is. I propose appending:
A file is considered tracked if it exists in a prior commit or in the
staging area. Note that a newly added file not in any prior commit will be
removed.
I would also like to propose that the staging area's tree object be saved,
perhaps in the reflog or perhaps just as a dangling object. This would allow
graceful recovery from git reset --hard. Witness the many questions and answers
on recovery:
http://stackoverflow.com/questions/7374069/undo-git-reset-hard-with-uncommitted-files-in-the-
staging-area
http://stackoverflow.com/questions/5788037/recover-from-git-reset-hard
http://stackoverflow.com/questions/5473/how-can-i-undo-git-reset-hard-head1
http://gitready.com/advanced/2009/01/17/restoring-lost-commits.html
https://bani.com.br/2014/10/recovering-lost-files-after-a-git-reset-hard/
https://medium.com/@CarrieGuss/how-to-recover-from-a-git-hard-reset-b830b5e3f60c
All of these solutions recover the contents of files, but not their names or the
directory structure. Saving the tree object somewhere (anywhere!) would solve
this problem.
I was bitten by this in a vicious way. I was setting up a new repository for a
bunch of code and data (git init; git add .), changed my mind about adding the
data (git reset --hard), and nearly lost everything. The only tree object that
could be found was an empty one, so I got file contents without names or
directories (not good, because experimental conditions for the data were encoded
in the directory structure).
Cheers,
Yotam��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�