Re: [PATCH 0/1] replay: add --revert option to reverse commit changes

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 28, 2025, 16:35 UTC
Message-ID: <xmqq7bvajesl.fsf@gitster.g>
In-Reply-To: <c930d6df-5dc4-401f-a9a1-eb2f00b2e837@gmail.com>

Siddharth Asthana <siddharthasthana31@gmail.com> writes:

> Agreed. I will keep the current submission focused on basic --revert 
> functionality. Supporting --no-walk for disconnected commits (benefiting 
> both --advance and --revert) would make a nice follow-up series.

If we want to have a useful support for disconnected set of commits, "--no-walk" is not the way to go, I would say.

Imagine "among the 7-patch topic merged, the second commit (i.e., topic~5) and the final 3 (i.e., topic~3..topic) need to go". You'd want to be able to say (without going into details of the syntax)

    revert topic~5 topic~3..topic

The setup_revisions() parser is still the right thing to use to parse the command line arguments and pick out "topic~5" and "topic~3..topic", but instead of letting prepare_revision_walk() turn them into a single contiguous set of revisions, you'd need to check revs->cmdline->rev[] and

 (1) treat singleton as its own disconnected island that require no
     walking,

 (2) treat A..B as a range and independently walk them, and

 (3) dedup the result from cmdline->rev[] elements into a set of
     commits that are potentially disconnected.

I agree 100% that this topic should not attempt to deal with a disconnected set of commits. That can and should be done as a separate series.