Question: behavior when reverting a commit from a shallow clone

Hi Git maintainers,

I have been investigating Git's behavior in a particular destructive scenario and wanted to verify my understanding with the maintainers.

Consider the following repository history:

A -> B

where A contains the repository's files and B is the current HEAD.

The repository is then cloned with:

git clone --depth=1 <repository>

so only B is available locally and its parent A is not present in the shallow clone.

If an operation is then performed to restore/revert B, I was looking into the behavior when the resulting working tree/index becomes empty — effectively causing all tracked files to be removed.

I have gone through the Git documentation and experimented with the relevant Git commands, including the behavior of shallow repositories, branch deletion, working-tree changes, resets, restores, and other destructive operations. Based on my investigation, I have not been able to find evidence that Git provides a warning or confirmation specifically when an operation results in all tracked files being removed or produces an empty tree.

Before drawing any conclusions, I wanted to verify this with the Git developers.

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.

Thanks, A fellow git user