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

[Junio C Hamano <gitster@pobox.com>]

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