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

["Carlisle T. Hamlin" <hamlin.carlisle@gmx.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 1539 bytes --]

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.



[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7951 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]