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

From: Patrick Steinhardt <ps@pks.im>
Date: Oct 5, 2026, 06:57 UTC
Message-ID: <asNKZpxiuFhVkVQd@pks.im>
In-Reply-To: <CALfz8Qx63qNoSbXq7C7u+KwX4=HCL7=uOUahpXd6j7KvW_c_Eg@mail.gmail.com>

On Sat, Oct 03, 2026 at 02:24:42PM +0530, Sphinx wrote:

Show 21 quoted lines

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

Yeah, this can indeed be surprising behaviour. The reason for it is that in a shallow clone, we rewrite the boundary commit (so in your case B) so that it doesn't have any parents anymore. It thus looks like just another root commit that has added all files in a single go. And the consequence of that is that reverting it will then delete everything.

Now arguably, Git could be improved here. We just recently had a similar discussion around maybe forbidding to "git commit --amend" such a shallow commit. Your scenario is a second one where Git should probably at least warn about what's happening.

Arguably we should even completely refuse editing such a shallow commit by default. I would guess that in 99% of all the cases where a user does it it's unintended. And for the 1% where it's actually intended we could give users a way to override this safeguard.

Show 15 quoted lines

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

Mostly correct. A small correction though: Git considers the empty _root_ tree to be a valid state so that you can create a commit that contains no files at all. We never write an empty sub-tree though, so you cannot add an empty directory.

> Git does not have a general safeguard that warns when an operation
> will delete all tracked files.

We try hard to not lose a user's data, so especially untracked data is something we're careful about. But anything that's committed already is fair game, as it's trivial to restore.

> If there are existing safeguards, warnings, configuration options, or
> historical discussions that I may have missed, I would appreciate any
> pointers.

There are none for the above use case, to the best of my knowledge.

Show 5 quoted lines

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

I wouldn't warn about an empty tree in general. But editing a commit that is a shallow boundary is something that I'd agree Git should warn about, if not even refuse by default.

Patrick