On 4/7/2023 3:24 AM, Christian Couder wrote: > From: Elijah Newren <newren@xxxxxxxxx> > > 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
