Prevent reset --hard from deleting everything if one doesn't have any commits yet

Prevent reset --hard from deleting everything if one doesn't have any commits yet

[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.

Re: Prevent reset --hard from deleting everything if one doesn't have any commits yet

[Johannes Sixt]

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

Re: Prevent reset --hard from deleting everything if one doesn't have any commits yet

[Manuel Guilamo]

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.



> 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

Re: Prevent reset --hard from deleting everything if one doesn't have any commits yet

[Jeff King]

On Fri, Mar 01, 2019 at 07:56:00AM +0100, Johannes Sixt 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.

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

Re: Prevent reset --hard from deleting everything if one doesn't have any commits yet

[Junio C Hamano]

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.