git-rev-list(1) orders the printed revisions before printing. This is
quite complicated and I noticed that it behaves in unexpected ways
w.r.t. commits given individually: sometimes they are reordered,
sometimes not. This is problematic when interdependent commits are given
via the command line individually: If they aren't re-ordered by
git-rev-list(1), we'd be cherry picking them in reverse order.
To solve this, just call git-rev-list(1) on all arguments individually,
allowing ranges to be resolved, but always picking individual arguments
in the correct order.
Notably, this means that excluding commits via individual REV^ arguments
won't ever work, but I believe this wasn't possible previously
anyways (maybe due to --no-walk?).
Change-Id: If8e83e0b47a74baf37d77b6c4f68a55af944b366
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13149
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
1115bffe47