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

> Koutsouflakis Stefanos <koutsouflakis.stefanos@proton.me> writes:
> > 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.
>
> The thinking has always been "'--hard' means what it says!  HARD
> removes things harder than other modes---there is need to add
> '--force' to it".

> On Wed, Dec 10, 2025 at 10:24 PM Junio C Hamano <gitster@pobox.com> wrote:
>> Koutsouflakis Stefanos <koutsouflakis.stefanos@proton.me> writes:
>> > 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.
>>
>> The thinking has always been "'--hard' means what it says!  HARD
>> removes things harder than other modes---there is need to add
>> '--force' to it".
>
> Presumably, you meant "there is *no* need" rather than "there is need".

> Koutsouflakis Stefanos <koutsouflakis.stefanos@proton.me> writes:
> > 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.
>
> The thinking has always been "'--hard' means what it says!  HARD
> removes things harder than other modes---there is need to add
> '--force' to it".

> 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.

> 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.

> 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

> Wouldn't the following slightly different scenario warrant a similar
> safety net:
>
>    git commit --allow-empty -m "Initial commit"
>    git add .
>    git reset --hard

> On Friday, December 12th, 2025 at 05:25, Junio C Hamano <gitster@pobox.com>
> wrote:
>
> > I doubt that special casing an empty tree would fly well.
>
> I might be missing something, could you say more about
> what makes this problematic?
> If it is about breaking existing workflows: any script that
> automates either of the two use-cases discussed would be relying
> on behavior that is almost certainly unintended. Such scripts
> would fail, but without data loss, and give authors a clear
> signal to fix a likely bug.
>
> > 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" :-/
>
> There might be other ways to mitigate this, e.g.:
> a) Refuse with a fatal error and hint the user
>    to remove staged content with "git rm --cached -r ."
> b) Autostash with a warning
>
> Thanks,
> Stefanos
>
>

> On Friday, December 12th, 2025 at 05:25, Junio C Hamano <gitster@pobox.com> wrote:
>
>> I doubt that special casing an empty tree would fly well.
>
> I might be missing something, could you say more about 
> what makes this problematic? 

> Inconsistency.
> 
> Treating "newly added files" specifically is making the behaviour
> inconsistent with others already, but doing so only when you haven't
> created a commit or after doing "checkout/switch --orphan", which is
> essentially what special-casing an empty tree case is about, makes
> it even more inconsistent.
> 
> > If it is about breaking existing workflows: any script that
> > automates either of the two use-cases discussed would be relying
> > on behavior that is almost certainly unintended.
> 
> 
> I do not think that is the reason for "special casing an empty tree
> would not fly well", but I have to say your view is too narow. I do
> rely on "reset --hard && clean -f -x" working in order to make the
> working tree spiffy clean, and I somehow doubt I am in the minority.
> And "reset --hard" MUST not fail in such a case.
> 
> > Such scripts
> > would fail, but without data loss, and give authors a clear
> > signal to fix a likely bug.
> 
> 
> And most authors will consider the "bug" to be fixed is in the
> degraded behaviour of "reset --hard". that does not do what is
> written on the label Then what?

>
> 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
>