fix(sterni/git-only-push): resolve args to revs individually

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>

users/sterni/git-only-push/git-only-push.sh

@@ -89,10 +89,7 @@ if [ "$#" -eq 0 ]; then
   die 100 "Missing commits"
 fi
 
-# Resolve ranges, get them into chronological order
 repo="$(git rev-parse --show-toplevel)"
-revs="$(git -C "$repo" rev-list --no-walk "$@" | tac)"
-
 worktree=
 
 cleanup() {
@@ -108,6 +105,10 @@ else
   git -C "$repo" worktree add "$worktree" "$base"
 fi
 
+for arg in "$@"; do
+  # Resolve ranges, get them into chronological order
+  revs="$(git -C "$repo" rev-list --no-walk "$arg" | tac)"
+
   for rev in $revs; do
     if $dry; then
       printf 'Would cherry pick %s\n' "$rev" >&2
@@ -122,6 +123,7 @@ for rev in $revs; do
       fi
     fi
   done
+done
 
 if $dry; then
   printf 'Would push resulting HEAD to %s on %s\n' "$to" "$remote" >&2