Re: Question: behavior when reverting a commit from a shallow clone
- From
- Sphinx <sphinx9692@gmail.com>
- Date
- Oct 5, 2026, 17:35 UTC
- Message-ID
- <CALfz8QxzXJ_0EC=a2AEO-_Qy+MGGnjHbE_8dBky23BLN-WnGPA@mail.gmail.com>
- In-Reply-To
- <CALfz8QzymKxvzYGWLwdtzERDm1apa8ebZEVyLne18hpTaB=D0g@mail.gmail.com>
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.