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

From: Matt Hunter <m@lfurio.us>
Date: Oct 5, 2026, 10:41 UTC
Message-ID: <DLWUB05MOV7T.2XA7NG57870ZD@lfurio.us>
In-Reply-To: <asNKZpxiuFhVkVQd@pks.im>

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