Re: [PATCH] sequencer: refuse to revert shallow boundary commits by default

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 21, 2026, 19:11 UTC
Message-ID: <xmqqqzhina26.fsf@gitster.g>
In-Reply-To: <7179f371-a709-476f-8e94-807d7b62ce6e@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 23 quoted lines

> Hi Nakul
>
> On 21/10/2026 11:09, Nakul V S via GitGitGadget wrote:
>> From: Nakul V S <vsnakul@gmail.com>
>> 
>> When a repository is cloned with --depth=1, Git records the boundary
>> commit in .git/shallow and rewrites its parent links via the graft
>> mechanism, making it appear as a root commit. Reverting such a commit
>> will therefore delete all tracked files, which is almost always
>> unintended by the user.
>> 
>> Add a check in do_pick_commit() that detects when the target commit is
>> a shallow boundary (nr_parent < 0 in the commit graft) and refuses the
>> operation by default. A new --allow-shallow-boundary flag is provided
>> for the rare cases where the user genuinely intends this behavior.
>
> Thanks for working on this, it is a useful and timely improvement as 
> there was some discussion about improving the behavior of git with 
> regard to shallow boundaries at the recent git merge conference. I 
> wonder if it would be better to refuse to cherry-pick and rebase a 
> shallow boundary commit as well. Do you know of a sensible use for 
> reverting a shallow boundary or is the new option added out of caution 
> in case someone wants it?

Very good point.

The next natural question is where the modification should go if we want to make sure we protect these shallow boundaries not just from revert but also from "cherry-pick", "rebase", and possibly "commit --amend". Is sequencer.c:do_pick_commit() the right place to cover all of them? If not, would it make sense to have a helper function that different code paths to protect shallow boundaries from these operations can call, and add the first call to that helper funcion to the location this patch adds new code to?

Thanks.