Re: [PATCH 11/14] replay: use standard revision ranges

From: Derrick Stolee <derrickstolee@github.com>
Date: Apr 14, 2023, 14:09 UTC
Message-ID: <8daf2603-2818-9c9d-7a06-6af2872a045a@github.com>
In-Reply-To: <20230407072415.1360068-12-christian.couder@gmail.com>

On 4/7/2023 3:24 AM, Christian Couder wrote:

Show 6 quoted lines

> From: Elijah Newren <newren@gmail.com>
> 
> Instead of the fixed "<oldbase> <branch>" arguments, the replay
> command now accepts "<revision-range>..." arguments in a similar
> way as many other Git commands. This makes its interface more
> standard and more flexible.

Unfortunately, while doing this, you have broken the --onto logic:

 $ git replay --onto HEAD~2 HEAD~1 HEAD
 fatal: replaying down to root commit is not supported yet!

The rev-walk you are supplying by this line...

> +	argc = setup_revisions(argc, argv, &revs, NULL);

is taking the remaining arguments and using them as tips to walk. We need to be able to recognize that --onto A B C means that A is the new base and our walk is B..C.

I'm not sure if there might be a way to use a callback for the --onto option and pull out the next three options into 'new-base', 'old-base', 'tip' values or something.

Overall, I don't think being flexible in the CLI is of high value for this command. Let's be as prescriptive as possible.

Something like:

	'git replay [options] <base> <tip>'
	This mode means to rebase <tip> onto <base>,
	detecting the range of commits to rewrite.

	'git replay [options] <new-base> <old-base> <tip>'
	This mode means to rebase the range <old-base>..<tip>
	onto <new-base>.

We don't even need "--onto" for these positional arguments.

Thanks, -Stolee