Re: Question: behavior when reverting a commit from a shallow clone

[Patrick Steinhardt <ps@pks.im>]

On Sat, Oct 03, 2026 at 12:41:47PM -0700, Carlisle T. Hamlin wrote:
> 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.

There really is no need to be this adversarial to a simple question like
from the author. We want to be a welcoming community, and replies like
this are the exact opposite and will drive people away.

Thanks!

Patrick