Question: behavior when reverting a commit from a shallow clone

8 messages between Oct 3, 2026 and Oct 5, 2026, from Sphinx, Carlisle T. Hamlin, Patrick Steinhardt, Matt Hunter, Junio C Hamano.

Plain Markdown or JSON for tools and agents.

SphinxOct 3, 2026, 08:54 UTC on lore

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

Carlisle T. HamlinOct 3, 2026, 19:41 UTC in reply to Sphinx on lore

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

On 10/3/26 1:54 AM, Sphinx wrote:

Show 18 quoted lines

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

Patrick SteinhardtOct 5, 2026, 06:57 UTC in reply to Carlisle T. Hamlin on lore

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

On Sat, Oct 03, 2026 at 12:41:47PM -0700, Carlisle T. Hamlin wrote:

Show 32 quoted lines

> 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

Patrick SteinhardtOct 5, 2026, 06:57 UTC in reply to Sphinx on lore

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

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

Matt HunterOct 5, 2026, 10:41 UTC in reply to Patrick Steinhardt on lore

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

On Mon Oct 5, 2026 at 2:57 AM EDT, Patrick Steinhardt wrote:

Show 11 quoted lines

> On Sat, Oct 03, 2026 at 02:24:42PM +0530, Sphinx wrote:
>> 
>> 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.

Separate question from the sidelines: As a non shallow clone user, this makes me wonder if/how these boundary commits might be munged to preserve original commit ids in the clone? eg: so a fast-forward pull still works for future content

Junio C HamanoOct 5, 2026, 16:38 UTC in reply to Matt Hunter on lore

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

"Matt Hunter" <m@lfurio.us> writes:

Show 17 quoted lines

> On Mon Oct 5, 2026 at 2:57 AM EDT, Patrick Steinhardt wrote:
>> On Sat, Oct 03, 2026 at 02:24:42PM +0530, Sphinx wrote:
>>> 
>>> 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.
>
> Separate question from the sidelines:  As a non shallow clone user, this
> makes me wonder if/how these boundary commits might be munged to
> preserve original commit ids in the clone?  eg: so a fast-forward
> pull still works for future content

Something similar to "graft" (and now "replace") is done under the hood, to stop history traversal machinery seeing the true parents of these boundary commits. As the commit object itself (specifically its "parent " lines in the header part) is not modified in any way, this does not affect object names.

SphinxOct 5, 2026, 17:35 UTC on lore

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

Thanks, Patrick. That makes it much clearer.

I was initially thinking of the empty tree as the potentially unsafe part, but from your explanation, it's clear that the empty tree itself isn't really the problem it's the shallow boundary that makes this behavior surprising.

The absence of a safeguard specifically for editing a shallow boundary commit, and the possibility of warning or refusing such operations by default, is exactly what I was trying to understand.

Thanks again for taking the time to explain it.

On Mon, Oct 5, 2026 at 10:44 PM Sphinx <sphinx9692@gmail.com> wrote:

Show 37 quoted lines

>
> Thanks, Patrick. That makes it much clearer.
>
> I was initially thinking of the empty tree as the potentially unsafe part, but from your explanation, it's clear that the empty tree itself isn't really the problem it's the shallow boundary that makes this behavior surprising.
>
> The absence of a safeguard specifically for editing a shallow boundary commit, and the possibility of warning or refusing such operations by default, is exactly what I was trying to understand.
>
> Thanks again for taking the time to explain it.
>
>
> On Mon, 5 Oct, 2026, 10:08 pm Junio C Hamano, <gitster@pobox.com> wrote:
>>
>> "Matt Hunter" <m@lfurio.us> writes:
>>
>> > On Mon Oct 5, 2026 at 2:57 AM EDT, Patrick Steinhardt wrote:
>> >> On Sat, Oct 03, 2026 at 02:24:42PM +0530, Sphinx wrote:
>> >>>
>> >>> 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.
>> >
>> > Separate question from the sidelines:  As a non shallow clone user, this
>> > makes me wonder if/how these boundary commits might be munged to
>> > preserve original commit ids in the clone?  eg: so a fast-forward
>> > pull still works for future content
>>
>> Something similar to "graft" (and now "replace") is done under the
>> hood, to stop history traversal machinery seeing the true parents
>> of these boundary commits.  As the commit object itself (specifically
>> its "parent " lines in the header part) is not modified in any way,
>> this does not affect object names.

Carlisle T. HamlinOct 5, 2026, 18:10 UTC in reply to Patrick Steinhardt on lore

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

On 10/4/26 11:57 PM, Patrick Steinhardt wrote:

Show 16 quoted lines

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

My apologies; I didn't realize I was coming across as adversarial.

Also, I stand corrected - other replies to this question indicate that we *are, indeed* prepared to perform this level of hand holding. I fundamentally misunderstood the project's stance in this regard.