I accidentally executed git reset —hard in a project that doesn’t have any commits yet. git erased everything, everything I’ve worked the past week, I believe this is not a desired behavior, considering I’m not able to undo that action, because git doesn’t have any history whatsoever.
threads / discuss / 50617
Prevent reset --hard from deleting everything if one doesn't have any commits yet
Subject: Prevent reset --hard from deleting everything if one doesn't have any commits yet
Johannes SixtRe: Prevent reset --hard from deleting everything if one doesn't have any commits yet
Am 28.02.19 um 22:43 schrieb Manuel Guilamo:
Show 5 quoted lines
> I accidentally executed git reset —hard in a project that doesn’t > have any commits yet. git erased everything, everything I’ve worked > the past week, I believe this is not a desired behavior, considering > I’m not able to undo that action, because git doesn’t have any > history whatsoever.
I tested this, and it does not happen for me as long as I do not `git add` anything.
So, I assume you did `git add` your content and then you did a `git reset --hard`. In that case, I'm afraid Git behaved as designed and "doesn't have any commits" is a red herring.
-- Hannes
Re: Prevent reset --hard from deleting everything if one doesn't have any commits yet
Oh yes... I did. Sigh
Regardless,
wouldn’t be nice to have a confirmation in cases like this? considering git isn’t only used by experts. It would’ve helped me A LOT, that’s for sure… and I’m 100% sure I won’t be that last person in the history of git that would suffer this.
Thank you for your quick reply.
Show 17 quoted lines
> On Mar 1, 2019, at 2:56 AM, Johannes Sixt <j6t@kdbg.org> wrote: > > Am 28.02.19 um 22:43 schrieb Manuel Guilamo: >> I accidentally executed git reset —hard in a project that doesn’t >> have any commits yet. git erased everything, everything I’ve worked >> the past week, I believe this is not a desired behavior, considering >> I’m not able to undo that action, because git doesn’t have any >> history whatsoever. > > I tested this, and it does not happen for me as long as I do not `git > add` anything. > > So, I assume you did `git add` your content and then you did a `git > reset --hard`. In that case, I'm afraid Git behaved as designed and > "doesn't have any commits" is a red herring. > > -- Hannes
Jeff KingRe: Prevent reset --hard from deleting everything if one doesn't have any commits yet
On Fri, Mar 01, 2019 at 07:56:00AM +0100, Johannes Sixt wrote:
Show 13 quoted lines
> Am 28.02.19 um 22:43 schrieb Manuel Guilamo: > > I accidentally executed git reset —hard in a project that doesn’t > > have any commits yet. git erased everything, everything I’ve worked > > the past week, I believe this is not a desired behavior, considering > > I’m not able to undo that action, because git doesn’t have any > > history whatsoever. > > I tested this, and it does not happen for me as long as I do not `git > add` anything. > > So, I assume you did `git add` your content and then you did a `git > reset --hard`. In that case, I'm afraid Git behaved as designed and > "doesn't have any commits" is a red herring.
Wouldn't that mean all of the file data is available in the object database? Unfortunately without an index, there's nothing to mark which file was which. But `git fsck --lost-found` should copy out all of the file content into .git/lost-found.
-Peff
Junio C HamanoRe: Prevent reset --hard from deleting everything if one doesn't have any commits yet
Jeff King <peff@peff.net> writes:
> Wouldn't that mean all of the file data is available in the object > database? Unfortunately without an index, there's nothing to mark which > file was which. But `git fsck --lost-found` should copy out all of the > file content into .git/lost-found.
If we had a hierachically stored index that stores subdirectory contents as a tree (or some tree-like things), "fsck --lost-found" would have been able to recover even pathnames, but with the current flat index in a fresh directory without any commit, we'd get bunch of blobs without any clue as to where each of them goes. It would be far better than nothing, but leaves room for improvement.