From: Junio C Hamano Date: Fri, 12 Dec 2025 03:24:07 GMT Subject: Re: [RFC] reset --hard: warn before discarding staged content with no commit history Message-ID: In-Reply-To: Johannes Sixt writes: > Wouldn't the following slightly different scenario warrant a similar > safety net: > > git commit --allow-empty -m "Initial commit" > git add . > git reset --hard Yes, I think everybody has lost new files not in an empty tree but more often (1) create a new file and add it, (2) make modifications to existing files, (3) compile, test, debug, get frustrated, and finally (4) decide to give up and start from scratch, with "reset --hard". When (1) is much larger than (2), the sense of loss is big. > That said, I have some sympathy for the case. Would it be palatable to > have `git reset --hard` refuse to do anything if the destination tree is > empty? I doubt that special casing an empty tree would fly well. It is tempting to special case removals, but then I sill am not sure it is good to do nothing and fail the command after determining that the operation is a common pitfall of removing a new file that appears nowhere else. Unconditionally going interactive is a no-no. And I do not have any better ideas. Other than just failing, that is. But that leads to nonsense combination "--hard --force", just as idiotic combination as "rm -f -i" :-/