From: Koutsouflakis Stefanos <koutsouflakis.stefanos@proton.me>
Date: Wed, 10 Dec 2025 15:01:36 GMT
Subject: [RFC] reset --hard: warn before discarding staged content with no commit history
Message-ID: <a5wKtD6Tn0gzcba1IEUhukYnXPHxMwPq6puQKIPywmjNufi5vc6vX-v5BpPJ7qj_zZsuXF5FiS2gbpsurWmVjoWHtMm8A-kAbaZyjMfrTcs=@proton.me>

When running "git reset --hard" in a repository where staged content
has never been committed, the staged files are lost. This seems like a case where requiring --force could be helpful.

Reproduction:

    mkdir test && cd test
    git init
    echo "hello" > a.txt
    git add .
    git reset --hard

Result: a.txt is removed from both the index and working tree.
While the blob temporarily remains as a dangling object (recoverable
via "git fsck --lost-found" until garbage collection), this is not a
realistic safety net as the filename is lost and most users are
unaware of this recovery mechanism.

The most likely scenario is a user initializing a Git repository in an
existing project. They have a folder with files they've been working on,
run "git init", then "git add ." to stage everything. A mistyped or
misunderstood command later, their entire project is wiped out.

Proposed behavior:

When "git reset --hard" would discard staged content that does not
exist in any commit (i.e., the blob has no reachable reference),
print a warning and require confirmation or --force:

    warning: the following staged files have never been committed
    and will be permanently lost:
        a.txt
    use --force to proceed, or commit first

This would be consistent with Git's general trend toward safer
defaults.

Questions for discussion:

1. Is this safety check worth the added complexity?

2. Are there workflows where this would be annoying? (can't think of any but I might be missing something).

I'm happy to work on a patch if there's interest.

Thanks,
Stefanos