From: Toon Claes Date: Tue, 31 Mar 2026 08:08:59 GMT Subject: Re: [PATCH v6 2/2] replay: add --revert mode to reverse commit changes Message-ID: <87o6k4l8tg.fsf@toon--20250203-5JQV3.mail-host-address-is-not-set> In-Reply-To: <1cf080ba-61a1-43b0-abff-c7c156c1c4b1@gmail.com> Tian Yuchen writes: > On 3/30/26 00:17, Siddharth Asthana wrote: > >>> >>> This is a fail-safe design intended to prevent users from entering >>> commands like: >>> >>>      git replay --revert main f1 f2 >>> >>> This operation is indeed undefined which should be intercepted. >>> However, considering: >>> >>>      git replay --revert main HEAD~5..HEAD~3 HEAD~1..HEAD >>> >>> Is this operation also intercepted? I think the reason is that the >>> condition 'rinfo->positive_refexprs > 1' is a bit too simplistic. >> >> >> Yes -- positive_refexprs counts each position tip, so that gives 2 and >> the > 1 check catches it. >> >> > > What I mean is, this operation shouldn't be intercepted, right? In my > view, it is valid to select and operate two (and more) periods from the > same linear commit history, but that is blocked here. So you want that command to replay the first revision range onto `main` and on top of that the second revision range? For what it's worth, I think `--advance` suffers from the same issue. So I think this can be addressed after these patches land. -- Cheers, Toon