git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
SSphinx <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.
Previous: Sphinx
Message 10 of 10 in “Question: behavior when reverting a commit from a shallow clone”
  1. SphinxOct 3, 2026
  2. Carlisle T. HamlinOct 3, 2026
  3. Patrick SteinhardtOct 5, 2026
  4. Carlisle T. HamlinOct 5, 2026
  5. Patrick SteinhardtOct 5, 2026
  6. Matt HunterOct 5, 2026
  7. Junio C HamanoOct 5, 2026
  8. Junio C HamanoOct 6, 2026
  9. SphinxOct 9, 2026
  10. SphinxOct 5, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.