From: Carlisle T. Hamlin Date: Sat, 03 Oct 2026 19:41:47 GMT Subject: Re: Question: behavior when reverting a commit from a shallow clone Message-ID: <54fac5f4-e49b-4384-af2c-615d7cc04ff5@gmx.com> In-Reply-To: On 10/3/26 1:54 AM, Sphinx wrote: > Is the following understanding correct? > > An empty tree is a valid Git state, so Git does not generally consider > transitioning from a non-empty tree to an empty tree inherently > erroneous. > > Git does not have a general safeguard that warns when an operation > will delete all tracked files. > > If there are existing safeguards, warnings, configuration options, or > historical discussions that I may have missed, I would appreciate any > pointers. > > The reason I am asking is that I am trying to establish precisely > where Git's safety boundary is in this scenario specifically, whether > Git itself is expected to warn about the resulting empty tree, or > whether detecting an unexpectedly destructive tree change is > considered the responsibility of the tooling performing the operation. You know, it seems to me that it should be reasonable for Git to assume that someone with the wherewithal to set up and operate a git repository (or at the very least operate one that someone else set up) knows enough to understand what's going to happen if they obliterate the only commit in their tree. There really is only *so* much holding of the hand I think we should be expected to perform before it's not only insulting to the project developers, but also to the *user*. My two cents. I know folk use Git for all sorts of stuff. Just, maybe... the sort of person who would be surprised catastrophically by this behaviour... well... shouldn't.