From: Toon Claes <toon@iotcl.com>
Date: Wed, 25 Mar 2026 15:10:30 GMT
Subject: Re: [PATCH v5 2/2] replay: add --revert mode to reverse commit changes
Message-ID: <87cy0s0wt5.fsf@iotcl.com>
In-Reply-To: <xmqqh5q4xvyw.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

> Siddharth Asthana <siddharthasthana31@gmail.com> writes:
>
>> diff --git a/builtin/replay.c b/builtin/replay.c
>> index 2cdde830a8..d3c1d920f0 100644
>> --- a/builtin/replay.c
>> +++ b/builtin/replay.c
>> @@ -83,7 +83,7 @@ int cmd_replay(int argc,
>> ... 
>>  	/* Parse ref action mode from command line or config */
>>  	ref_mode = get_ref_action_mode(repo, ref_action);
>>  
>> +	/*
>> +	 * Cherry-pick/rebase need oldest-first ordering so that each
>> +	 * replayed commit can build on its already-replayed parent.
>> +	 * Revert needs newest-first ordering (like git revert) to
>> +	 * reduce conflicts by peeling off changes from the top.
>> +	 */
>> +	int desired_reverse = !opts.revert;
>> +
>
> Compiler notices -Werror=declaration-after-statement error here.

That's basically the only comment I have on this series.

Except for one micro-hit on the existing docs about <revision-range>:

    <revision-range>::
    	Range of commits to replay; see "Specifying Ranges" in
    	linkgit:git-rev-parse[1]. In `--advance <branch>` mode, the
    	range should have a single tip, so that it's clear to which tip the
    	advanced <branch> should point. Any commits in the range whose
    	changes are already present in the branch the commits are being
    	replayed onto will be dropped.

Next to --advance, we should also mention --revert. But that's totally
not worth a reroll and can be addressed in any other later series.

-- 
Cheers,
Toon