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

From: Sphinx <sphinx9692@gmail.com>
Date: Oct 9, 2026, 17:34 UTC
Message-ID: <CALfz8Qx+BMNqQsV0tVTFDQ++vkZ3NCLnN2Wt+KUSNDBRSJ6Prw@mail.gmail.com>
In-Reply-To: <xmqqbj96g6zj.fsf@gitster.g>

Thank you both. I wanted to follow up with a slightly more concrete framing of what a safeguard could look like, in case it is useful as a starting point.

Git already tracks shallow boundary commits in .git/shallow, so detection is possible at the point where a destructive operation is about to be applied to one. A minimal version of this safeguard could look like:

  - Before executing git revert (and maybe git commit --amend)
    on a commit OID, check whether that OID appears in .git/shallow.
  - If it does, refuse by default with a message explaining that the
    commit is a shallow boundary and suggesting either
    --allow-shallow-boundary to proceed or git fetch --unshallow
    to restore full history before retrying.

Refusing rather than just warning seems appropriate given that, as Patrick noted, the overwhelming majority of such operations are unintentional.

I am happy to attempt a patch for git revert as a starting point if this direction seems worth pursuing. Let me know if there are constraints or prior discussions I should be aware of before doing so.

Thanks

On Tue, Oct 6, 2026 at 9:24 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 37 quoted lines

>
> Patrick Steinhardt <ps@pks.im> writes:
>
> > 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.
> >
> > Now arguably, Git could be improved here. We just recently had a similar
> > discussion around maybe forbidding to "git commit --amend" such a
> > shallow commit. Your scenario is a second one where Git should probably
> > at least warn about what's happening.
> >
> > Arguably we should even completely refuse editing such a shallow commit
> > by default. I would guess that in 99% of all the cases where a user does
> > it it's unintended. And for the 1% where it's actually intended we could
> > give users a way to override this safeguard.
>
> Yeah, I think that line of thinking is going in the right direction.
>
> It is not surprising that these non-core features (read: as opposed
> to really core features that were already considered mature even
> back in Git 1.5.3) that had many years to mature still has rough
> edges even today around corners that practicaly nobody has touched,
> and we should not be afraid to round them further.
>
> > I wouldn't warn about an empty tree in general. But editing a commit
> > that is a shallow boundary is something that I'd agree Git should warn
> > about, if not even refuse by default.
>
> Yes.  Committing an empty tree, whether at the beginning of a
> project or in the middle of a project after you fed up with too many
> bugs in your early attempts and want to start clean, is a perfectly
> normal, if wasteful, thing to do.
>
> Thanks.