From: Junio C Hamano Date: Mon, 05 Oct 2026 16:38:53 GMT Subject: Re: Question: behavior when reverting a commit from a shallow clone Message-ID: In-Reply-To: "Matt Hunter" 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.