Re: git reset --hard should not irretrievably destroy new files

From: Johannes Sixt <j6t@kdbg.org>
Date: Dec 3, 2016, 07:49 UTC
Message-ID: <f2f8c7c9-cbe0-870d-3c13-fc928dd91dd1@kdbg.org>
In-Reply-To: <CAJZCeG1Eu+5DfaxavX_WGUCa+SY+yepDWZhPXxiFcV__h0xjrw@mail.gmail.com>

Am 03.12.2016 um 06:04 schrieb Julian de Bhal:

> If you `git add new_file; git reset --hard`, new_file is gone forever.

AFAIC, this is a feature ;-) I occasionally use it to remove a file when I already have git-gui in front of me. Then it's often less convenient to type the path in a shell, or to pointy-click around in a file browser.

> git add new_file

Because of this ...

> git add -p                       # also not necessary, but distracting
> git reset --hard                 # decided copy from backed up diff
> # boom. new_file is gone forever

... it is not. The file is still among the dangling blobs in the repository until you clean it up with 'git gc'. Use 'git fsck --lost-found':

--lost-found

     Write dangling objects into .git/lost-found/commit/ or 
.git/lost-found/other/, depending on type. If the object is a blob, the 
contents are written into the file, rather than its object name.

-- Hannes