From: D. Ben Knoble Date: Fri, 12 Dec 2025 22:14:28 GMT Subject: Re: [RFC] reset --hard: warn before discarding staged content with no commit history Message-ID: In-Reply-To: On Wed, Dec 10, 2025 at 10:04 AM Koutsouflakis Stefanos wrote: > > 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 > Perhaps useful for future readers who are looking for ways to recover the objects: https://blog.plover.com/prog/git-reset-disaster.html -- D. Ben Knoble