Open Alizter opened 10 months ago
The parsing for this has been implemented and it has been integrated into the request-review
command in mainline.
The behavior I implemented for handling errors with batched commands in request-review
was to NOT have it short circuit the application. Instead it allows the other batched patch index ranges to run as well. I did this to maintain the behavior of the batch-request-review
command which already had this behavior. I also think that this behavior makes sense for the request-review
command as I don't believe previous patch index ranges should have any impact on the later ones requesting review.
However, even though we have the parsing available to all of the commands. I think that the behavior we want for other commands may be different. For example if we talk about integrate
it can run a pull
at the end of each integrate
which would rebase the patch stack and then the patch index ranges wouldn't match correctly for the following patch index ranges.
So my point is that we likely just need to think through each of the cases where we want batching support and determine what type of behavior we want for that command when batching.
Now that we have a proper syntax for patch series
1-3
, we can think about adding multiple arguments to certain commands in an unambiguous way from a parsing standpoint. The idea is that agps command
followed by multiple rather than a single series:gps command 1 2-3 4-7
should batch said commands to something likegps command 1; gps command 2-3; gps command 4-7
.This will subsume commands like
gps batch-request-review
.Now there are some questions that we need to answer in order to fully develop this idea.