From: Sphinx Date: Fri, 09 Oct 2026 17:34:01 GMT Subject: Re: Question: behavior when reverting a commit from a shallow clone Message-ID: In-Reply-To: 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 wrote: > > Patrick Steinhardt 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.