[RFC] reset --hard: warn before discarding staged content with no commit history

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