From: Koutsouflakis Stefanos Date: Thu, 11 Dec 2025 16:33:08 GMT Subject: Re: [RFC] reset --hard: warn before discarding staged content with no commit history Message-ID: In-Reply-To: On Thursday, December 11th, 2025 at 14:34, Johannes Sixt wrote: > Am 11.12.25 um 12:53 schrieb Koutsouflakis Stefanos: > > > On Wed, Dec 10, 2025 at 10:24 PM Junio C Hamano gitster@pobox.com wrote: > > > > > The thinking has always been "'--hard' means what it says! HARD > > > removes things harder than other modes---there is [no] need to add > > > '--force' to it". > > > > I agree that "--hard" conveys serious intent. But I would argue > > there is a meaningful difference between "lose your uncommitted > > changes" and "lose your entire project". > > > > To be clear, I'm addressing a very narrow scenario: > > the user has run init on an existing codebase, staged files > > with git add, but has not yet made a first commit. Running > > reset --hard at this point destroys the entire project > > with no realistic recovery path. This is almost certainly > > never intentional. > > I would argue that bad "tutorials" and "recipes" are to blame. I have > seen far too many that casually suggest `git reset --hard` without > warning and in an easy to copy-and-paste format. Agreed. Many users copy-paste their way through Git or use commands they don't fully understand. That's not the ideal way to interact with Git, but they don't deserve do be punished. > 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? > > -- Hannes Good point. Checking for an empty destination tree seems to be the better approach. Refusing to proceed (without providing the option of bypassing it with --force) also seems reasonable, maybe with a helpful message explaining the reason. On a second thought "--hard --force" is a bit redundant, like "rm -rf --really-delete". Thanks, Stefanos